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Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ARQ Admission ReQuest 

CMS Cryptographic Message Syntax 

DCF Disengage ConFirm 

DRQ Disengage ReQuest 

DES Data Encryption Standard 

DSA Digital Signature Algorithm 

DTD Document Type Definition 

FIPS PUBS Federal Information Processing Standards Publications 

HTML HyperText Markup Language 

HTTP Hypertext Transfer Protocol 

IETF Internet Engineering Task Force 

IOTP Internet Open Trading Protocol 

IP Internet Protocol 

IPSEC Internet Protocol SECurity 

MD5 Message Digest 5 

MIME Multipurpose Internet Mail Extensions 

NIST National Institute of Standards and Technology 

NTP Network Time Protocol 

OSP Open Settlement Protocol 

PIN Personal Identification Number (e.g. for automated teller machines) 

PKCS Public Key Cryptography Standard 

RAS Registration Admission and Status 

RSA Rivest Shamir Adleman 

SDP Session Description Protocol 

SHA Secure Hash Algorithm 

SIP Session Initiation Protocol 

S/MIME Secure Multipurpose Internet Mail Extensions 

SSL Secure Socket Layer 

TCP Transmission Control Protocol 

TLS Transport Layer Security 

URL Uniform Resource Locator 

UTC Universal Time Co-ordinated 

UTF Universal Text Format 

XML extensible Markup Language 
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4 Open settlement protocol architecture 

This clause introduces the protocol architecture for the OSP specification. It identifies the major protocols used by 
communicating parties, and it outlines their relationship to each other. The clause also describes the overall format of 
messages exchanged by the protocols. The intent of this clause is to outline the framework for the standard's protocols 
and message formats; later clauses detail specific profiles for these protocols and the specific message content. 



4.1 Communication protocols 



As figure 1 shows, systems conforming to the OSP specification use a combination of the Hypertext Transfer Protocol 
(HTTP), and either the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) to transfer pricing, authorization, 
and usage information. As the figure indicates, these protocols are layered on top of the Transmission Control Protocol 
(TCP) for communication across Internet Protocol (IP) networks. 



OSP 



XML (presentation) 



HTTPvl .0 



SSLv3 



TCP port 443 



TCP port 80 



IP 



Figure 1 : Open Settlement Protocol architecture for pricing, 
authorization, and usage exchange 

4.1 .1 Secure Sockets Layer (SSL)/Transport Layer Security (TLS) 

The Secure Sockets Layer and Transport Layer Security protocols add authentication and privacy to TCP connections. 
SSL is the standard protocol for securing web browsing. As such, it is widely deployed on the Internet and is 
distinguished by considerable operational experience. SSL also enjoys near universal support from firewalls and proxy 
servers. TLS is an updated version of SSL currently being developed within the Internet Engineering Task Force 
(IETF). TLS is heavily based on SSL and, although it is not strictly backwards compatible with SSL, systems 
supporting both TLS and SSL can automatically recognize either protocol and adapt as required to ensure 
interoperabihty. 

NOTE: As other industry standard mechanisms for IP-based security (for example, IPSEC) reach maturity, later 
revisions to the present document may incorporate support for those mechanisms in addition to SSL/TLS. 
Such revisions to the security mechanisms may also permit the use of an unreliable transport such as 
UDP. 

4.1 .2 HyperText Transfer Protocol (HTTP) 

The HyperText Transfer Protocol (HTTP) is the standard protocol for web-based communications. HTTP has been 
adopted for a wide variety of purposes including proxy services, bi-directional content delivery, database access, 
network management, and metering information. HTTP is by far the most widely used application protocol on the 
Internet, and is supported by all significant firewalls and proxy servers. 



4.2 Message format 



To illustrate the overall format of OSP messages, figure 2 shows an example message. As the figure indicates, the 
content within the HTTP message is formatted according to the standard for Multipurpose Internet Mail Extensions 
(MIME). The individual components of the message are a document conforming to the Extensible Markup Language 
(XML) specification and a Secure MIME (S/MIME) digital signature. 

NOTE: The digital signature is optional and, if omitted, the message content consists solely of a XML document. 
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HTTP Header 



Message Content 



Digital Signature 



POST scripts/settlements HTTP/1.0 
content-type: multipart/signed; 

protocol="application/pkcs 7 -signature" ; 

micalg=shal ; 

boundary=bar 
content-length: 844 




-bar 



Content-Type : application/pkcs7-signature 
Content-Length: 191 

GhyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF4 67GhIG 
fHfYT64VQpfyF4 67GhIGfHfYT6jH7 7n8HHGghyHhHUujhJh7 5 6t 
bB9HGTrfvbnjn8HHGTrfvhJhjH7 7 6tbB9HG4VQbnj75 67GhIGfH 
fYT6ghyHhHUujpfyF47GhIGfHfYT64VQbnj756 

— bar — 

Figure 2: Example message showing overall format 

4.2.1 Multipurpose Internet Mail Extensions (MIME) 

All messages exchanged as part of this OSP specification conform to the Multipurpose Internet Mail Extensions 
(MIME) specification. The MIME specification defines mechanisms to combine individual components of arbitrary 
format (e.g. text, graphics, audio information, binary data, etc.) into a single message. Originally designed for electronic 
mail, the MIME specification has been adapted for a variety of communication applications, including web browsing. 
MIME format is widely supported by existing firewalls and proxy servers. 



4.2.2 eXensible Markup Language (XML) 

The first part of each MIME message is a document conforming to the Extensible Markup Language (XML) standard. 
As an extension of the widely deployed Hypertext Markup Language (HTML), XML can be readily parsed by firewalls 
and proxy servers. Unlike HTML, though, XML is readily extensible and can easily support rich, structured data such 
as pricing and usage information. 

4.2.3 Secure MIME 

The second part of each MIME message, if present, is a digital signature conforming to the Secure Multipurpose 
Internet Mail Extensions (S/MIME). S/MIME format includes support for multiple digest and signing algorithms and 
for variable cryptographic strength (e.g. key lengths). S/MIME format is also self-identifying with respect to these 
parameters, so that a recipient can derive the necessary information for verifying the signature from the signature data. 
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NOTE: This does not imply that the recipient is guaranteed to be able to verify the signature, only that the 
recipient can tell what it needs to perform the verification. (So that, for example, the recipient may 
identify a signing algorithm that it does not support). 



Protocol profiles 



This clause specifies the profiles for the protocols required by the present document. It identifies the normative 
references to those protocols, as well as the specific versions, options, and extensions that the present document 
requires. The specific protocols described in this clause are the Secure Sockets Layer (SSL) and Transport Layer (TLS) 
protocols and the Hypertext Transfer Protocol (HTTP). The clause concludes by specifying the overall format of the 
messages conveyed through these protocols. Clauses 5.1 to 5.2.7 describe the message content in detail. 

5.1 Secure Sockets Layer (SSL)/Transport Layer Security 
(TLS) 

If secure authentication of the server is desired, or if confidentiality of the information exchanged between client and 
server is desired, the communication between the devices shall be secured using the Secure Sockets Layer (SSL) or 
Transport Layer Security (TLS) as described in this clause. 

5.1.1 Protocol version 

Conforming systems shall support version 3.0 of the Secure Sockets Layer protocol [5] to secure their communications. 

NOTE: As an implementation option, systems may support version 1 .0 of the Transport Layer Security 
protocol [23] or later versions. 

5.1 .2 Client/server roles 

When initiating a communication as part of the present document, the initiating system shall act as an SSL/TLS client 
while the responding system shall act as an SSL/TLS server. 

5.1.3 CipherSuites 

Annex B documents the cryptographic algorithms required and recommended by the present document, including 
SSL/TLS ciphersuites. 

5.2 Hypertext transfer protocol 

5.2.1 Protocol version 

Conforming systems shall support version 1.0 of the Hypertext Transfer Protocol [1] as the base transfer protocol for 
their messages. 

NOTE: As an implementation option, systems may support HTTP version LI [3]. 

5.2.2 Client/server roles 

When initiating a communication as part of the present document, the initiating system shall act as an HTTP client, 
while the responding system shall act as an HTTP server. 



5.2.3 TCP port 



Clients shall support sending their requests to TCP port 443 if SSL/TLS is being used, and to TCP port 80 otherwise. As 
an implementation option, communicating parties may agree to communicate via other TCP ports. 
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5.2.4 HTTP methods 



Requests from clients to a server shall be in the form of HTTP request messages using the POST method. Responses 
from a server shall consist of valid HTTP response messages. 

5.2.5 Uniform resource identifier 

The uniform resource identifier included in the POST request is not specified in the present document, but rather is 
subject to prior agreement between the communicating parties. 

5.2.6 HTTP headers 

The HTTP header of the POST method shall minimally consist of the request-line. All request-header and 
general-header fields are optional. If present, they shall conform to the HTTP standard [1]. The status-line for the HTTP 
responses shall be present in those responses, and it shall conform to the HTTP standard, including status-code and 
reason-phrase values. All response-header and general-header fields are optional. If present, they shall conform to the 
HTTP standard. 

5.2.7 HTTP entity body 

Each message (i.e. HTTP entity body) conveyed as part of the present document shall conform to the Multipurpose 
Internet Mail Extensions standard [4], and shall, if signed, consist of exactly two parts, an Extensible Markup Language 
document and a Secure Multipurpose Internet Mail Extensions digital signature, as specified in the following two 
clauses. The highest level structure for each message shall conform to the multipart/signed syntax defined in 
S/MIME [17]. The message's media type shall be "multipart/signed" with appropriate parameters (e.g. protocol of 
"application/pkcs7-signature" and micalg of "shal.") The entity shall indicate the correct content-length value, as 
defined in the HTTP standard [ 1 ] . 

If not signed, each message shall simply consist of a single, text/plain part. 

If bulk transfer is used, the entire message should be signed. 



6 XML content 

This clause specifies the actual message format used by the OSP to exchange pricing, authentication and authorization, 
and usage information. It outlines the overall XML document structure, lists the individual XML elements, and 
describes how those elements are combined into exchanges. 

6.1 Docunnent Structure 

6.1 .1 Multipurpose Internet Mail Extensions Conformance 

As the first part of a Multipurpose Internet Mail Extensions (MIME) message, each message content shall conform to 
the MIME standard [4] as indicated in clauses 6.1.1.1 to 6.1.1.3. 

6.1.1.1 Content-type 

The message's content-type shall be designated text/plain. 

NOTE: It is anticipated that the Internet Engineering Task Force (IETF) will eventually define a MIME 
content-type for XML documents (e.g. text/xml). When such a definition is available, subsequent 
revisions of the present document may specify the use of that content-type instead of text/plain. 

6.1.1.2 Content-length 

All messages shall indicate the correct content-length value as defined in the MIME standard. 
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6.1.1.3 



Transfer encoding 



As XML documents can be carried within the HTTP protocol in their native format, no transfer encoding 
(e.g. quoted-printable or base-64) shall be used. 

NOTE: Since XML content is carried in its native encoding, that encoding will not conform to the 

recommendations for the text/plain content-type. In particular, the XML encoding specifies the use of a 
single line-feed character (#xA) to indicate line ending rather than the return/line-feed pair. Although not 
the default encoding for text/plain, such an encoding does not violate the MIME standard. 

6.1.2 XML conformance 

The actual message content itself shall conform to the XML standard [2]. As part of that conformance, systems shall 
follow the well-formedness and character encoding requirements as follows. 



6.1.2.1 



XML version 



Message content shall conform to version 1 .0 of the XML standard, and shall indicate that version with the required 
XML prologue of <? xml version="l . 0"?>. 



6.1.2.2 



Well-formed constraint 



All messages shall be well-formed XML documents, as defined in the [2] standard. Messages may be valid XML 
documents as well, by referencing the appropriate XML document type definitions (DTDs). Strict validity (as defined 
by [2]) is not required, however. 

NOTE: The terms "well-formed" and "valid" have specific meanings with the XML standard, and are used to 
indicate specific degrees of conformance to the standard. 



6.1.2.3 



Character encoding 



Messages may use any character set permitted by the XML standard. As specified in that standard, however, all 
implementations shall be capable of generating and interpreting UTF-8 and UTF-16 encodings. In the absence of 
explicit knowledge that the receiving system can support other character encodings, sends shall use UTF-8 or UTF-16 
encoding [22]. 

6.1.3 XML framework 

All messages shall conform to the overall framework illustrated in figure 3. As the figure shows, messages consist of a 
single root entity, which contains one or more components, each of which consists in turn of one or more elements. 
These elements may include XML attributes. 



<component> 



<element> 



<element> 



<message> 



<element> 



<component> 



<element> 



<element> 



<element> 



Figure 3: Overall XML framework 
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6.1.3.1 Root entity 



<!DOCTYPE Message [ 

< [ELEMENT Message ( ( Pricinglndication | PricingConf irmation | AuthorizationRequest I 

AuthorizationResponse | Authorizationlndication | AuthorizationConf irmation | Usagelndication | 

UsageConf irmation | ReauthorizationRequest 1 ReauthorizationResponse 1 

SubscriberAuthenticationRequest I SubscriberAuthenticationResponse 1 Capabilitieslndication | 

CapabilitiesConf irmation )+ )> 
<!ATTLIST Message messageld ID #REQUIRED 
random CDATA #REQUIRED> 

]> 

The root entity for each message shall be a Message element. It shall contain the components documented above, as 
well as a unique identifier attribute and a random attribute. 

6.1.3.2 Random attribute 

Each Message element shall include a random attribute. This attribute's value shall be a random number, encoded as a 
decimal character string. The attribute ensures that each message contains some random content, and it therefore 
increases the security of the S/MIME digital signature. 

NOTE: Systems should use a cryptographically strong random number generator as the source for this attribute's 
value. Standard library random number functions (such as from the ANSI C standard) are generally not 
cryptographically strong, and should not be used. 

6.1.3.3 Identifier attribute 

Each message and each component within a message shall include a unique identifier for that element. The system that 
initiates communication (through either a request or an indication) shall ensure that the identifier is unique. The system 
that replies (through either a response or a confirmation) shall use the identifier value to associate messages and 
components in its response or confirmation with the corresponding elements in the request or indication. The identifier 
attribute consists of an arbitrary character string, and is indicated by the attribute names messageld or 
component Id, as appropriate. 

6.1.3.4 Critical attribute 

All XML elements shall include a special attribute with the name critical that takes values of "true " or 
"false". This attribute indicates whether or not processing of the message can safely proceed if the particular element 
is not supported by the receiver. 

If a system receives a component containing a critical element that it does not support, that system shall not accept or 
process the component. 

If the critical attribute is omitted from an element (and its parents), that element shall be treated as if the critical 
attribute was present with the value "true ". 

The value of the critical attribute (whether explicit or implied) for an element shall apply to all sub-elements of the 
element unless a sub-element explicitly indicates otherwise. 

6.1.3.5 Extensions 

Organizations may define additional elements or components beyond those documented in the present document. To 
ensure that no two organizations use the same named element, all private extensions shall have, as a prefix to their 
name, an officially registered Internet domain name belonging to the defining party. That domain name may be 
separated from the element name by a colon. If, for example, the organization that owns the Internet domain name 
acme.com wishes to add an element named PrivateOption, the tags delineating that element will be 
<acme . com: PrivateOption> and </acme . com: PrivateOption>. As noted above, the critical 
attribute may be used to indicate to a recipient whether or not it can safely ignore a private extension that it does not 
understand or support. 
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6.2 Components 



Components are the main elements within each message. The <Message> element shall contain at least one and may 
contain more than one component. The components defined in the present document include pairs to effect pricing 
exchange (Pricinglndication and PricingConf irmation), obtain authorization 
(AuthorizationRequest and AuthorizationResponse), verify authorization 
(Authorizationlndication and AuthorizationConf irmation), refresh authorization 
(ReauthorizationRequest and ReauthorizationResponse), report usage (Usagelndication and 
UsageConf irmation), authentication subscribers (SubscriberAuthenticationRequest and 
SubscriberAuthenticationResponse) and exchange capabilities (Capabilitieslndication and 
Capabi 1 it iesConf irmation). 



6.2.1 Pricinglndication 



<!ELEMENT Pricinglndication ( Timestamp, Sourcelnfo, Destinationlnfo, Currency, Amount, Increment, 

Unit, Service, ValidAfter, ValidUntil )> 
<!ATTLIST Pricinglndication componentid ID #REQUIRED> 

A Pr icinglndicat ion component identifies the price for a particular service. It is composed of several elements, 
as indicated above. 

For example, the following XML content states that the cost of basic telephone calls from the United States (country 
code 1) to France (country code 33) is US$ 0,50 per minute, effective immediately and indefinitely. 

<PricingIndication component I d=" 1234567890 "> 
<Timestamp> 

1997-05-02T19:03:00Z 
</Timestamp> 
<SourceInfo type="el 64pref ix"> 
1 
</SourceInf o> 
<DestinationInf o tYpe="el54pref ix"> 
33 
</DestinationInfo> 
<Currency> 
USD 
</Currency> 
<Amount> 
0.5 
</Amount> 
<Increment> 
60 
</Increment> 
<Unit> 
s 
</Unit> 
<Service/> 

<ValidAfter/> 
<ValidUntil/> 
</PricingIndication> 

NOTE: The Pricinglndication component maybe sent in bulk transfer. If bulk transfer is used, then the 
digital signature should be mandatory. The digital signature is described in clause 5.2.7. 

6.2.2 PricingConfirmation 

<! ELEMENT PricingConfirmation ( Timestamp, Status )> 
<!ATTLIST PricingConfirmation componentid ID #REQUIRED> 

A PricingConfirmation component indicates acceptance or rejection of the corresponding 
Pricinglndication. The componentid attribute associates the confirmation with the indication. The only 
elements within the PricingConfirmation are the Timestamp and Status elements. 



£75/ 



18 ETSI TS 101 321 V4.1.1 (2003-11) 

NOTE: The PricingConf irmation component may be sent in bulk transfer. If bulk transfer is used, then the 
digital signature should be mandatory. The digital signature is described in clause 5.2.7. 

6.2.3 AuthorizationRequest 

<!ELEMENT AuthorizationRequest ( Timestamp, Callld*, Sourcelnfo, SourceAlternate*, 
Destinationinf o, DestinationAlternate*, Service, MaximumDestinations, Token*, 
SubscriberAuthenticationlnfo*, Sessionid*, MultiSessionld*, Group* )> 

<!ATTLIST AuthorizationRequest componentid ID #REQUIRED> 

An AuthorizationRequest asks for authorization to use resources. In the context of basic Internet telephony 
service, it asks for authorization to complete a phone call. The call, for example, may be identified by ITU-T 
Recommendation E. 164 [11] numbers in the Sourcelnfo and Destinationlnfo elements. The requesting 
system may leave the choice of peer endpoints up to the authorizing server, or it may specify the peer endpoint itself in 
a DestinationAlternate element. 

The client shall provide one or more Callld elements in the request. A single Callld element implies that the client 
wishes to use that call identifier for all possible destinations returned in the AuthorizationResponse. Multiple 
Callld elements imply that the client wishes each potential destination to have its own call identifier. If the client 
wishes to specify multiple call identifiers, the number of C a 1 II d elements shall be equal to the value of the 
MaximumDestinations element. 

The AuthorizationRequest message may request either authorization information, call routing information, or 
both. When requesting authorization information only, clients shall specify a MaximumDestinations value of 
zero (0). When requesting call routing information only, clients may omit any SourceAlternate elements that 
identify a subscriber, and they may include a Token received as the result of a prior authorization. In addition, clients 
may include previously received SubscriberAuthenticationlnfo elements. 

In order to authorize a group, OSP client A might indicate in the Group element the parameter on which authorization 
shall be based. 

If a Group element is included in the AuthorizationRequest component, then the Destinationlnfo 
element shall identify the range of valid destination domain addresses. The Sourcelnfo element should not be 
included. The SourceAlternate element should identify the source domain. 

NOTE 1: The use of the AuthorizationRequest message is not intended to be a replacement for, or 

supersede any ITU-T Recommendation H.323 [12] Registration Admission and Status (RAS) messages. 
Although the elements of the AuthorizationRequest are similar to information elements in RAS 
messages, AuthorizationRequest is intended for use in the bulk transfer of authorization tokens or 
other scenarios in which RAS signalling would not be appropriate. 

NOTE 2: The present document permits either party in an authorization exchange to determine the call routing 

information (e.g. identifying the peer endpoint for the call). If the client wishes to explicitly specify call 
routing, it does so by including one or more DestinationAlternate elements (e.g. of type 
"transport" containing the IP address and port number of the peer endpoint) in the 
AuthorizationRequest. If the server is performing call routing, it returns the information in the 
AuthorizationResponse. The DestinationAlternate elements are advisory during the 
request. The server should attempt to use one of the endpoints specified, but it is free to substitute a 
different set of endpoints if it is unable to settle the call using those specified. 

If no routing is required, this shall be explicitly indicated by setting MaximumDestinations to "0". 
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6.2.4 AuthorizationResponse 



<!ELEMENT AuthorizationResponse ( Timestamp, Status, Transactionld, Token*, Destination*, Service?, 

Group* ) > 

<!ATTLIST AuthorizationResponse componentid ID #REQUIRED> 

An AuthorizationResponse component returns authorization information corresponding to an 
AuthorizationRequest. It includes a Timestamp, a Status element, a Transactionld, optional tokens, 
zero or more Destination elements, and optional QualityOf Service and Group elements. Any tokens present 
are assumed to apply to all destinations. The response includes a componentid attribute to associate it with the 
appropriate AuthorizationRequest. 

If the requested QoS cannot be granted then the Service element should indicate the highest level of QoS available. 

The use of the Group element is defined in clause 8.3.1. 

NOTE: If a client has expressed its own call routing preferences in the AuthorizationResponse (e.g. with 
DestinationAlternate elements of type transport), then the server should make every attempt 
to honour those preferences by returning appropriate Destination elements. The server may also 
include alternative destinations in its response. 

6.2.5 Authorizationlndication 

<!ELEMENT Authorizationlndication ( Timestamp, Role, Callld, Sourcelnfo, SourceAlternate*, 

Destinationinf o, DestinationAlternate*, Service, Token* )> 
<!ATTLIST Authorizationlndication componentid ID #REQUIRED> 

An Authorizationlndication asks for verification of previously issued authorization, typically by asking for 
verification of an authorization token. Because tokens may be opaque to the terminating endpoint, that endpoint may 
not be able to determine the originator of a particular token. It is therefore acceptable to pass an entire sequence of 
tokens from a setup message in this component, and it is acceptable to send simultaneous 
Authorizationlndication messages to multiple servers. The server shall be capable of recognizing 
authorization tokens in addition to validating them. 

NOTE: Even though the present document defines messages for validating authorization tokens, it does not 

require their use. In particular, some tokens may be constructed so that they can be completely verified in 
the peer system (e.g. through the use of digital signatures). 

6.2.6 AuthorizationConfirmation 

<!ELEMENT AuthorizationConfirmation ( Timestamp, Status, ValidAfter, ValidUntil )> 
<!ATTLIST AuthorizationConfirmation componentid ID #REQUIRED> 

An AuthorizationConfirmation component indicates whether or not an authorization is valid. It includes a 
Timestamp, a Status element and validation time limits. The confirmation also includes a componentid attribute 
to associate it with the appropriate Authorizationlndication. 



6.2.7 Usagelndication 



<!ELEMENT Usagelndication ( Timestamp, Role, Transactionld, Callld, Sourcelnfo, SourceAlternate*, 

Destinationinf o, DestinationAlternate*, UsageDetail*) > 
<!ATTLIST Usagelndication componentid ID #REQUIRED> 

The Usagelndication component reports resource usage. In the context of basic Internet telephony service, this is 
typically call duration. 

NOTE: The Usagelndication component may be sent in bulk transfer. If bulk transfer is used, then the 
digital signature should be mandatory. The digital signature is described in clause 5.2.7. 
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6.2.8 UsageConfirmation 

<! ELEMENT UsageConfirmation ( Timestamp, Status )> 
<!ATTLIST UsageConfirmation componentid ID #REQUIRED> 

A UsageConfirmation component indicates acceptance or rejection of the corresponding Usagelndication. 
The componentid attribute associates the confirmation with the indication. The only elements within the 
UsageConfirmation are the Timestamp and Status elements. 

NOTE: The UsageConfirmation component maybe sent in bulk transfer. If bulk transfer is used, then the 
digital signature should be mandatory. The digital signature is described in clause 5.2.7. 

6.2.9 ReauthorizationRequest 

<!ELEMENT ReauthorizationRequest ( Timestamp, Role, Callld, Sourcelnfo?, SourceAlternate*, 

Destinationlnfo?, DestinationAlternate*, Transactionid, UsageDetail*, Token* )> 
<!ATTLIST ReauthorizationRequest componentid ID #REQUIRED> 

A ReauthorizationRequest component requests a reauthorization of a previously authorized service. A client 
may use this message, for example, if a previous authorization has expired. 



6.2.10 ReauthorizationResponse 



<!ELEMENT ReauthorizationResponse ( Timestamp, Status, Transactionid, Token*, Destination* )> 
<!ATTLIST ReauthorizationResponse componentid ID #REQUIRED> 

A ReauthorizationResponse component indicates acceptance or rejection of the corresponding 
ReauthorizationRequest. Any tokens present are assumed to apply to all destinations. The componentid 
attribute associates the response with the request. 

6.2.1 1 SubscriberAuthenticationRequest 

<!ELEMENT SubscriberAuthent icat ionRequest (Timestamp, Sourcelnfo, SourceAlternate*, 

Destinationlnfo?, Service?) > 
<!ATTLIST SubscriberAuthenticationRequest componentid ID #REQUIRED> 

A SubscriberAuthenticationRequest asks for authentication of a subscriber's credentials, typically in the form of a 
ISO/IEC 7812-1 [29] identification card number and associated personal identification number. 

6.2.12 SubscriberAuthenticationResponse 

<!ELEMENT SubscriberAuthent icat ionResponse (Timestamp, Status, SubscriberAuthenticationlnfo*) > 
<!ATTLIST SubscriberAuthenticationResponse componentid ID #REQUIRED> 

A SubscriberAuthenticationResponse component returns an indication of whether the subscriber's credentials are 
considered authentic. 



6.2.13 Capabilitieslndication 



<!ELEMENT Capabilitieslndication (Devicelnfo*, OSPVersion, OSPCapability*, Resources?) > 
<!ATTLIST Capabilitieslndication componentid ID #REQUIRED 

critical ( true I false ) #FIXED "false"> 

To identify the OSP features it should use with a particular server, a client sends that server a 

Capabilitieslndication message. That message indicates the highest version of OSP that the client is willing 
to support, as well as the specific capabilities it wishes to use. The server responds with a 

CapabilitiesConf irmation message. This message indicates the version of OSP that the two parties should use 
for their communication, and it provides the client details about how to use the services it requires. 

If the server responds to a Capabilitieslndication message with anything other than a 
CapabilitiesConf irmation message (e.g. an error status), the client should assume that the server is only 
capable of support for V 1 .4.2 of the present document. 
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6.2.14 CapabilitiesConfirmation 



<!ELEMENT CapabilitiesConfirmation (Timestamp, Status, OSPVersion, OSPService*, Certif icateChain*, 

Deviceld?) > 
<!ATTLIST CapabilitiesConfirmation componentid ID #REQUIRED 

critical (true t false) #FIXED "false"> 

The CapabilitiesConfirmation message allows a server to specify the OSP capabilities that clients should use 
to communicate with it. It is sent in response to a Capabilities Indication. The information consists of a 
version number, an optional list of services supported, and an optional set of certificate chains. The version element 
specifies the version of OSP to which future communications shall conform. This version number shall be equal to or 
less than the version number proposed in the client's Capabilities Indication. The services list provides the 
client with information it needs to access various OSP services. The Certif icateChain elements provide 
certificate chains for public keys that the server will use to sign any authorization tokens it supplies. 

6.3 Elements 

This clause defines the individual elements that make up each message component. 

6.3.1 Amount 

<! ELEMENT Amount (#PCDATA)> 

<!ATTLIST Amount critical (true 1 false) "true"> 

The Amount element identifies a numeric value and is often associated with the Increment and Unit elements, as 
well as the Currency element. Amounts are expressed using the period (.) as a decimal separator and with no 
punctuation as the thousands separator. The following excerpt, for example, expresses a rate of 50 cents (US) per 
minute. 

<CurrencY> 

USD 
</Currency> 
< Amount > 

0.5 
</Amount> 
<Increment> 

60 
</Increment> 
<Unit> 

s 
</Unit> 

6.3.2 AuthorityURL 

<! ELEMENT AuthorityURL (#PCDATA)> 

<!ATTLIST AuthorityURL critical (true | false) "true"> 

The AuthorityURL element identifies a uniform resource locator (URL) by which authorization may be verified or 
refreshed. 



6.3.3 Callld 



<!ELEMENT Callld (#PCDATA)> 






<!ATTLIST Callld encoding (cdata 


i base64) 


"cdata" 


critical (true | 


false) 


"true"> 



The Callld element contains a call's ITU-T Recommendation H.323 [12] Callld value, and is thus used to uniquely 
identify individual calls. To convey its binary value, a call identifier may either be encoded using XML CDATA format 
and appropriate escape sequences, or it may be encoded with base64 encoding as per the [4] standard. An encoding 
attribute indicates the method selected, and the default value for that attribute is XML CDATA. 
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6.3.4 Code 



<! ELEMENT Code (#PCDATA)> 

<!ATTLIST Code critical (true [ false) "true"> 

The Code element contains the numeric value that uniquely and unambiguously indicates the sender's response to a 
request or indication. It is usually paired with a Description element within a Status element. The Code content 
consists of three numeric digits in the form NNN. The first (most significant) digit indicates the success or failure of the 
operation, subsequent digits provide greater detail. Values defined by the present document include the following: 

NOTE: Subsequent revisions to the present document may add other code values, but will always preserve the 
meaning of a most significant 2 as success, and any other most significant digit as failure. 

2 XX = operation successful 

2 00 = success (no other information) 

2 01 = information created (no previous values) 

210 = updated information accepted (previous values replaced) 

4 XX = request failure 

4 00 = bad request (generic problem interpreting message) 

4 01 = unauthorized (user authentication failed) 

4 02 = payment required 

4 03 = forbidden (route blocked) 

4 04 = not found (no route to destination) 

4 05 = source may not originate call to destination 

410 = character encoding not supported 

411 = parsing unsuccessful 

412 = critical element not supported 

4 2 = generic security problem (no other information available) 

4 21 = signature invalid 

4 22 = cryptographic algorithm not supported 

4 2 3 = certificate invalid 

4 2 4 = certificate revoked 

4 2 5 = encryption required 

4 2 8 = Sourcelnfo invalid or missing 

4 41 = temporary failure 

4 4 7 = resource unavailable (route to destination may not terminate) 

4 4 9 = quality of service unavailable 

4 5 = requested facility is not subscribed 

4 63 = service or option not available 

4 81 = call ID invalid or missing 

4 88 = incompatible destination 

4 95 = invalid message 

5 XX = server error 

500 = internal server error 

5 01 = not implemented 

5 03 = service not available 

510 = transient problem in server 

52 = long term problem in server 

5 30 = time problem 

5 31 = valid time too soon 

5 32 = time interval too small 

999 = generic failure (no other information available) 
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6.3.5 Currency 



<! ELEMENT Currency (#PCDATA)> 

<!ATTLIST Currency critical (true \ false) "true"> 

The Currency element defines the financial currency in use for the parent element. It is represented according to the 
notation of ISO 4217 [6]. In addition, the following definitions not included in ISO 4217 [6] may be used: 

ECU European Currency Unit 

EUR Euro 

SDR Special Drawing Rights 



6.3.6 Description 



<!ELEMENT Description (#PCDATA)> 

<!ATTLIST Description critical (true I false) "false"> 

The Description element provides a textual description for a response, and is typically paired with a Code element 
as part of a Status parent element. The Description element is for informational purposes only, as the Code 
element defines the behaviour. Suggested values for the Description element are the descriptions given above for 
each Code value. 

6.3.7 Destination 

<!ELEMENT Destination ( Destinationinf o?, DestinationAlternate*, DestinationSignalAddress, Token*^ 

ValidAfter?, ValidUntil?, UsageDetail*, AuthorityURL*, DestinationProtocol?, Callld*, 
Sessionid*, MultiSessionld*, Group* )> 
<!ATTLIST Destination critical (true | false) "true"> 

The Destination element is the parent element for call routing information, and it is returned by servers in an 
AuthorizationResponse messages. As the above definition shows, as many as ten different types of subelements 
may comprise a Destination element. 

6.3.8 DestinationAlternate 




The DestinationAlternate element contains secondary identification of the destination. This information 
provides an alternative to the Destinationinf o element. DestinationAlternate uses the same notation as 

Destination Info. 

6.3.9 Destination Info 



<!ELEMENT Dest inat ioninf o (#PCDATA) 


> 








<!ATTLIST Destinationlnfo type 


( el64 1 h323 I url | email 
international I national I 


1 transport I 
network 1 








subscriber 1 abbreviated I 


el64prefix ) 


♦REQUIRED 




critical 


( true 1 false ) 




"true" 


> 



The Destinationlnfo element gives the primary identification of the destination, or called party, for a call. The 
element includes a type attribute, and can take one of several forms depending on the value of that attribute. 

The following list indicates the contents of the element, given each possible attribute type. 

e 1 6 4 full ITU-T Recommendation E. 1 64 [11] telephone number containing numeric digits 

only (i.e. no punctuation) 
h323 ITU-T Recommendation H.323 [12] identifier 

url Uniform Resource Locator [12] 

email electronic mail address [12] 
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transport transport address is the form of name:nn where name is the domain name (or IP address 

enclosed in square brackets) and :nn is an (optional) TCP or UDP port number, 
(e.g. [172.16.1. 1]:112) 

international international party number [12] 

national national party number [12] 

network network specific party number [12] 

subscriber subscriber party number [12] 

abbreviated abbreviated party number [12] 

el64prefix initial (most significant) digits of an ITU-T Recommendation E. 164 [11] number with no 

punctuation 

6.3.10 DestinationSignalAddress 

<!ELEMENT DestinationSignalAddress (#PCDATA)> 

<!ATTLIST DestinationSignalAddress critical (true \ false) "true"> 

The DestinationSignalAddress element identifies the call signalling address for the destination. It is represented as 
name:nn, where name is a domain name or an IP address enclosed in square brackets. The :nn is optional and indicates a 
TCP port number. 

Example 1: Call signalling to device gateway.operator.com at TCP port number 1 12 is represented as follows: 

<DestinationSignalAddress> 
gateway . operator . com: 112 
</DestinationSignalAddress> 

Example 2: Call signalling to an operators association using unique identifiers for each affiliated service provider is 
represented as follows: 

<DestinationSignalAddress> 

operator . com/contactid 
</DestinationSignalAddress> 

6.3.11 Increment 

<! ELEMENT Increment (#PCDATA)> 

<!ATTLIST Increment critical (true \ false) "true"> 

The Increment element indicates the number of units being accounted. It is typically used in combination with the 
Amount and Unit elements. The following excerpt, for example, expresses a duration of 5,5 minutes. 

<Amount> 

5.5 
< /Amount > 
<Increment> 

60 
</Increment> 
<Unit> 

s 
</Unit> 

6.3.12 MaximumDestinations 

<!ELEMENT MaximumDestinations (#PCDATA)> 

<!ATTLIST MaximumDestinations critical (true [ false) "true"> 

The MaximumDestinations element appears in the AuthorizationRequest component to indicate the 
maximum number of potential destinations the client wishes to receive in the response. 
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6.3.13 Role 

<! ELEMENT Role (#PCDATA)> 

<!ATTLIST Role critical (true [ false) "true"> 

The Role element indicates the role of the system generating a message. It shall contain one of the following values: 
source message generated by source; 
destination message generated by destination; 
other message generated by systems other than source or destination. 

6.3.14 Service 

<!ELEMENT Service ( ServiceType?, Bandwidth?, QualityOf Service? )> 
<!ATTLIST Service critical (true | false) "true"> 

The Service element indicates a type of service being priced, authorized, or reported. If the ServiceType Element 
is not present: voice is the default service. If the Bandwidth element is present, it indicates the bandwidth required for 
or consumed by the service. The QualityOf Service element indicates QoS classes or QoS parameters. 



6.3.15 SourceAltemate 



<!ELEMENT SourceAltemate (#PCDATA) 


> 










<!ATTLIST SourceAltemate type 


( 


el64 1 h323 I url | email i transport | 
international I national | network 
subscriber | abbreviated 1 el64prefix 
pin 1 epin 1 deviceld ) #REQUIRED 


iso7812 1 






critical 


( 


true 1 false ) 




"true" 


> 



The SourceAltemate element contains secondary identification of the source of a call. It conforms to the same 
notation as the Destinationlnfo element. 

The additional types specific to source information are iso7812, pin, and epin. They are defined as follows: 

iso7 812 ISO/IEC standard 7812-1 [29] identification card number containing numeric digits only (i.e. no 

punctuation) 

pin Personal identification number containing numeric digits only (i.e. no punctuation) 

epin Encrypted personal identification number, base64 encoded. The encryption procedure is as 

follows: 

1 . Pad the PIN, represented as ASCII decimal digits, with nulls (binary zeroes) to a multiple 
of 16 octets. 

2. Concatenate a 128-bit random number to the shared secret (shared by the OSP server and 
client). 

3. Calculate a one-way hash of the resulting concatenation using the Message Digest 5 
algorithm. 

4. Exclusive-OR the result with the padded PIN. 

5. Concatenate the resulting value after the original 128-byte random and base64 encode the 
resulting 256-byte quantity. 

deviceld server-assigned identifier. 
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6.3.16 Sourcelnfo 



<!ELEMENT Sourcelnfo (#PCDATA) 


> 










<!ATTLIST Sourcelnfo type 


( el64 1 h323 I 


url 1 email 


1 transport I 








international 


national I 


network | subscriber 








abbreviated t 


el64prefix 


iso7812 1 pin [ epin 


deviceld ) 






♦REQUIRED 










critical 


( true i false ; 


1 




"true" 


> 



The Sourcelnfo element contains the primary identification of the source of a call. It uses the same notation as the 
Destinationinf o element, along with the additional types defined for SourceAlternate. 

6.3.17 SourceSignalAddress 

<!ELEMENT SourceSignalAddress (#PCDATA)> 

<!ATTLIST SourceSignalAddress critical (true \ false) "true"> 

The SourceSignalAddress element identifies the call signalling address of the source of a call. It uses the same 
notation as the DestinationSignalAddress element. 

6.3.18 Status 

<!ELEMENT Status ( Code, Description? )> 
<!ATTLIST Status critical (true | false) "true"> 

The Status element reports the results of a response or confirmation. It is composed of a Code element and an 
optional Description element. 

For example, the following excerpt indicates a successful response or confirmation: 

<Status> 
<Code> 

200 
</Code> 
<Description> 

success (no other information) 
</Description> 
</Status> 



6.3.19 Timestamp 



<! ELEMENT Timestamp (#PCDATA)> 

<!ATTLIST Timestamp critical (true I false) "true"> 

The Timestamp element indicates the time at which the component was generated. It is represented by a restricted form 
of ISO 8601 [7] format. In particular, time is always represented in co-ordinated universal time (UTC) using the 
notation YYYY-MM-DDThh : mm : s s Z where: 

YYYY = four-digit year (for example, 1998); 

MM = two-digit month (01=January, etc.); 

DD = two-digit day of month (01 through 31); 

T = indicates division between date and time; 

hh = two-digit hour (00 through 23); 

mm = two-digit minute (00 through 59); 

ss = two-digit second (00 through 59); 

Z = indicates co-ordinated universal time. 
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For example, exactly 3:03 P.M. on May 2, 1997, Eastern Daylight Time in the United States, is represented as: 

<Timestamp> 

1997-05-02T19:03:00Z 
</Timestamp> 

6.3.20 Token 



<! ELEMENT Token (#PCDATA)> 






<!ATTLIST Token encoding (cdata 


1 base64) 


"cdata" 


critical (true 


false) 


"true"> 



The Token element conveys a security token. To convey its binary value, a token may either be encoded using XML 
CDATA format and appropriate escape sequences, or it may be encoded with base64 encoding as per the [4] standard. 
An encoding attribute indicates the method selected, and the default value for that attribute is XML CDATA. 

6.3.21 Transaction Id 

<!ELEMENT Transact ionid (#PCDATA)> 

<!ATTLIST Transactionid critical (true [ false) "true"> 

The Transactionid element contains an integer, decimal valued identifier assigned to a specific authorized 
transaction. It is represented without any punctuation (e.g. no thousands separator). 

6.3.22 Unit 

<! ELEMENT Unit (#PCDATA)> 

<!ATTLIST Unit critical (true | false) "true"> 

The Unit element indicates the units by which pricing is measured or usage recorded. It shall contain one of the 
following values: 



s 


seconds; 


pkt 


packets (datagrams); 


byte 


bytes. 


page 


fax pages 


call 


calls 



6.3.23 UsageDetail 



<!ELEMENT UsageDetail (Service, Amount, Increment, Unit, StartTime?, EndTime?, TerminationCause?, 

Statistics? )> 
<!ATTLIST UsageDetail critical (true I false) "true"> 

The UsageDetail element collects information describing the usage of a service. Individual transactions may 
combine multiple UsageDetail elements as part of their usage report. This capability supports both parallel services 
(e.g. audio and video streams during a video conference) and serial services (e.g. low bit-rate codec switching to a 
higher quality codec as network conditions deteriorate). 

The UsageDetail element may also be present in either an AuthorizationResponse or a 
ReauthorizationResponse. In that case, it indicates a limit to the authorization. For example, an 
AuthorizationResponse that includes a UsageDetail of (amount = 3, increment = 60, unit = s) indicates that 
the authorization is valid for no more than 3 minutes of service. 
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6.3.24 ValidAfter 

<! ELEMENT ValidAfter (#PCDATA)> 

<!ATTLIST ValidAfter critical (true i false) "true"> 

The ValidAfter element identifies the time and date after which the component's information shall be effective or 
valid. It is encoded using the same notation as the Timestamp element. If this element is empty, component 
information is assumed to be valid as soon as it is received. 



6.3.25 ValidUntil 

<!ELEMENT ValidUntil (#PCDATA)> 

<!ATTLIST ValidUntil critical (true I false) "true"> 

The ValidUntil element identifies the time and date after which the component's information is no longer effective 
or valid. It is encoded using the same notation as the Timestamp element. If this element is empty, component 
information is assumed to be effective indefinitely, or until it is explicitly modified with new information. 

6.3.26 EndTime 



<! ELEMENT EndTime (#PCDATA)> 

<!ATTLIST EndTime critical (true I false) #FIXED "false"> 

The EndTime element indicates the time at which the service ended. It is encoded using the same notation as the 
Timestamp element. 

6.3.27 StartTime 

<! ELEMENT StartTime (#PCDATA)> 

<!ATTLIST StartTime critical (true 1 false) #FIXED "false"> 

The StartTime element indicates the time at which the service started. It is encoded using the same notation as the 
Timestamp element. 

6.3.28 TCCode 

<! ELEMENT TCCode (#PCDATA)> 

<!ATTLIST TCCode critical (true [ false) #FIXED "false"> 

The TCCode element contains the numeric value that uniquely and unambiguously indicates the internet telephony 
transaction's status code. It is usually paired with a Description element within a TerminationCause element. 
The TCCode content consists of four numeric digits in the form NNNN. The first (most significant) digit indicates the 
success (1) or failure (0) of the operation, subsequent digits provide greater detail. Values defined by the present 
document include the following: 

0001 = unallocated (unassigned) number; 

0002 = no route to specified transit network; 

0003 = no route to destination; 

0004 = send special information tone; 

0005 = misdialed trunk prefix; 
000 6 = channel unacceptable; 

0007 = call awarded and being delivered in an established channel; 

0008 = preemption; 

000 9 = preemption - circuit reserved for re-use; 

1016 = normal call clearing; 

0017 = user busy; 

0018 = no user responding; 

0019 = no answer from user (user alerted); 
002 = subscriber absent; 

0021 = call rejected; 
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0022 = number changed; 

002 6 = non-selected user clearing; 

002 7 = destination out of order; 

002 8 = invalid number format (address incomplete); 

002 9 = facility rejected; 

0030 = response to STATUS ENQUIRY; 

0031 = normal, unspecified; 

0032 = no circuit/channel unavailable; 
0038 = network out of order; 

003 9 = permanent frame mode connection out of service; 

004 = permanent frame mode connection operational; 
0041 = temporary failure; 

004 2 = switching equipment congestion; 

004 3 = access information discarded; 

004 4 = requested circuit/channel not available; 

004 6 = precedence call blocked; 

004 7 = resource unavailable, unspecified; 

004 9 = quality of service unavailable; 

005 = requested facility not subscribed; 
005 3 = outgoing calls barred within CUG; 
005 5 = incoming calls barred with CUG; 
005 7 = bearer capability not authorized; 

005 8 = bearer capability not presently available; 

00 62 = inconsistency in designated outgoing access information and subscriber class; 

00 63 = service or option not available, unspecified; 

00 65 = bearer capability not implemented; 

00 66 = channel type not implemented; 

00 69 = requested facility not implemented; 

007 = only restricted digital information bearer capability is available; 

007 9 = service or option nit implemented, unspecified; 

0081 = invalid call reference value; 

0082 = identified channel does not exist; 

0083 = a suspended call exists, but this call identity does not; 

0084 = call identity in use; 
00 85 = no call suspended; 

008 6 = call having the requested call identity has been cleared; 

0087 = user not member of CUG; 

0088 = incompatible destination; 
00 90 = non-existent CUG; 

00 91 = invalid transit network selection; 

00 95 = invalid message, unspecified; 

00 96 = mandatory information element is missing; 

00 97 = message type non-existent or not implemented; 

00 98 = message not compatible with call state or message type non-existent or not implemented; 

00 99 = information element/parameter non-existent or not implemented; 

0100 = invalid information element contents; 

0101 = message not compatible with call state; 

0102 = recovery on timer expiry; 

0103 = parameter non-existent or not implemented, passed on; 

0110 = message with unrecognized parameter, discarded; 

0111 = protocol error, unspecified; 
012 7 = interworking, unspecified. 
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6.3.29 TerminationCause 

<!ELEMENT TerminationCause (TCCode, Description? ) > 

<!ATTLIST TerminationCause critical (true | false) #FIXED "false"> 

The TerminationCause element reports the resuhs of an internet telephony transaction. It is composed of the 
TCCode element and an optional Description element. 

For example, the following excerpt indicates a successful termination cause: 

<TerminationCause> 
<TCCode> 
1016 
</TCCode 
<Description> 

normal call clearing 
</Description> 
</TerminationCause> 

6.3.30 Certificate 

<!ELEMENT Certificate (#PCDATA)> 

<!ATTLIST Certificate encoding (cdata I base64) "base64" 
critical (true 1 false) #FIXED "false"> 

This element contains a public key certificate. To convey its binary value, a certificate may either be encoded using 
XML CDATA format and appropriate escape sequences, or it may be encoded with base64 encoding as per the [4] 
standard. An encoding attribute indicates the method selected, and the default value for that attribute is base64. 

6.3.31 CertificateCiiain 

<!ELEMENT Cert if icateChain (Certificate* ) > 

<!ATTLIST Certif icateChain critical (true I false) #FIXED "false"> 

This element contains a certificate chain. The first certificate is the subject's certificate. It is followed by any 
intermediate certificate authorities (in order) and concludes with the certificate for the root authority. 



6.3.32 OSPCapability 



<! ELEMENT OSPCapability (#PCDATA)> 

<!ATTLIST OSPCapability critical (true I false) #FIXED "false"> 

This element identifies a particular OSP capability that a server can provide to a client. Capabilities are identified by the 
name of the component that the client sends to the server to invoke them. A client that wishes to send 
AuthorizationRequest messages to a server, for example, would include the following XML in its 

Capabilitieslndication message. 

<OSPCapability critical="f alse"> 

AuthorizationRequest 
<OSPCapability> 
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6.3.33 OSPService 



<!ELEMENT OSPService (OSPCapability, OSPServiceURL*, OSPSignatureRequired) > 
<!ATTLIST OSPService critical (true \ false) #FIXED "false"> 

The OSPService element provides information a client needs to obtain a particular service from an OSP server. The 
specific service is identified by the OSPCapability element. OSPServiceURL elements, if present, indicate the 
URL(s) the client should use to request the service. They appear in order of decreasing priority (e.g. the primary URL 
appears first), and, if none are present in the OSPService element, then the client may rely on other means to obtain 
the information. (It may, for example, simply use the same URL it used for the Capabilitieslndication. 
Message.) The final element, OSPSignatureRequired, is a Boolean value that indicates whether or not the server 
requires that request for the specified service to the identified URLs to be digitally signed. This explicitly allows for a 
server to indicate one set of URLs for signed messages of a particular type and a different set for unsigned messages of 
that same type. When such an option is available, the decision as to whether or not to sign messages is an 
implementation choice for the client. One possible strategy would be to first attempt to use the unsigned option, falling 
back to the signed option if the server responds with a security error. 

6.3.34 OSPServiceURL 

<!ELEMENT OSPServiceURL (#PCDATA)> 

<!ATTLIST OSPServiceURL critical (true I false) #FIXED "false"> 

The OSPServiceURL element identifies the uniform resource locator (URL) a client should use for a particular OSP 
service. 

6.3.35 OSPSignatureRequired 

<!ELEMENT OSPSignatureRequired (#PCDATA)> 

<!ATTLIST OSPSignatureRequired critical (true I false) #FIXED "false"> 

The OSPSignatureRequired element indicates whether or not a server requires that requests for the indicated 
service be digitally signed. It shall contain one of the following values: 

true signatures are required; 
false signatures are not required. 

6.3.36 OSPVersion 

<!ELEMENT OSPVersion (#PCDATA)> 

<!ATTLIST OSPVersion critical (true | false) #FIXED "false"> 

The OSPVersion element identifies the highest version of TS 101 321 that the sender is willing to support. The 
sender is assumed to support all publicly released versions of the specification up to and including the indicated value. 
For example, the following XML fragment indicates that the sender can support OSP versions 1.4.2 and 2.1.1. 

<OSPVersion critical = "false"> 

2.1.1 
</OSPVersion> 



6.3.37 SubscriberAutinenticationlnfo 



<!ELEMENT SubscriberAuthent icat ioninf o (#PCDATA)> 






^ 


<!ATTLIST SubscriberAuthenticationlnfo encoding (cdata 


1 base64) 


"cdata" 




critical (true 1 


false) 


#FIXED 


"false"> 



Opaque information that a server creates to confirm the authentication of a subscriber. The server returns this element as 
part of the SubscriberAuthenticationResponse message, and clients should include it in subsequent 
AuthorizationRequest messages for the subscriber. 
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6.3.38 Devicelnfo 



<!ELEMENT Devicelnfo (#PCDATA) > 












<!ATTLIST Devicelnfo type ( el64 | h323 


1 url 1 email 


1 








transport 1 


serialnumber | 


customerld ) 


♦REQUIRED 






critical ( true 


1 false ) 




#FIXED 


"false" 


> 



The Devicelnfo element allows a device to identify itself to a server when sending a 

Capabilitieslndication message. In addition to the standard Sourcelnfo types, clients may use the 
following types to identify themselves: 

serialnumber manufacturer's serial number or equivalent for the device; 
customerld user-assigned value for the device. 

6.3.39 Deviceld 

<!ELEMENT Deviceld (#PCDATA) > 

<!ATTLIST Deviceld critical (true I false) "false" > 

The Deviceld element allows a server to provide an identifier to a client in a CapabilitiesConf irmation 
message. The client may then use that identifier in subsequent messages to the server. 

6.3.40 Resources 

<!ELEMENT Resources ( DataRate?, AlmostOutOfResources? ) > 
<!ATTLIST Resources critical ( true 1 false ) #FIXED "false" > 

The Resources element allows a client to indicate its resources and their current status, as part of a 
Capabilitieslndication message. 

6.3.41 DataRate 

<! ELEMENT DataRate ( NumberOf Channels?, Bandwidth ) > 

<!ATTLIST DataRate critical ( true 1 false ) #FIXED "false" > 

DataRate describes the load that the client can handle. 

6.3.42 NumberOfChannels 

<! ELEMENT NumberOfChannels (#PCDATA) > 

<!ATTLIST NumberOfChannels critical (true I false) #FIXED "false" > 

The NumberOfChannels element is positive integer, indicating the number of channels available on the client to 
service calls for a particular protocol. 



6.3.43 Bandwidth 



<! ELEMENT Bandwidth (#PCDATA) > 

<!ATTLIST Bandwidth critical (true I false) #FIXED "false" > 

The Bandwidth element is a positive integer. When the NumberOfChannels element is present, it indicates the 
available bandwidth (in bits/sec) of each channel on the client to service calls for a particular protocol. When the 
NumberOfChannels element is not present. Bandwidth represents the total bandwidth (in bits/sec). 
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6.3.44 AlmostOutOfResources 

<!ELEMENT AlmostOutOfResources (#PCDATA) > 

<!ATTLIST AlmostOutOfResources critical (true I false) #FIXED "false" > 

The AlmostOutOfResources element is a flag from the client to the server. It shall contain one of the following 
values: 

true if the client might run out of resources shortly to accept new calls 
false if the client has sufficient resources to accept new calls. 

6.3.45 DestinationProtocol 

<!ELEMENT DestinationProtocol (#PCDATA) > 

<!ATTLIST DestinationProtocol critical ( true I false ) #FIXED "false"> 

The DestinationProtocol element indicates the session, or call, control protocol of the destination, or called 
party, for a call. It contains one of the following values : 

h32 3 destination supports ITU-T Recommendation H.323 

s ip destination supports IETF RFC 3261 Session Initiation Protocol 

6.3.46 QualityOfService 

<!ELEMENT QualityOfService (QoSClass? t QoSParameters? ) > 
<!ATTLIST QualityOfService critical (true | false) "true" > 

The QoSClass element indicates either one of 256 speech QoS classes or the QoS parameters. 



6.3.47 QoSClass 



<!ELEMENT QoSClass (QoSClass? I QoSParameters? ) > 
<!ATTLIST QoSClass critical (true 1 false) "true" > 

The QoSClass element indicates one of 256 speech QoS classes or the TC classes. 



Name 


Meaning 


TO 


Predefined 


T1 
T2 

T3 
T4 
T5 


Best (TS 101 329-2 [30]) 
High (TS 101 329-2 [30]) 
Medium (TS 101 329-2 [30]) 
Acceptable (TS 1 01 329-2 [30]) 
Best effort (TS 101 329-2 [30]) 


T6 
To 
T16 


for future ETSI standardization 


T17 

To 

T255 


User defined 


TCx 

To 

TCxx 


To be defined by ITU-T 



6.3.48 QoSParameters 

<!ELEMENT QoSParameters (Delay, Jitter, Packless) > 
<!ATTLIST QoSParameters critical (true 1 false) "true"> 

The QoSParameters element contains the Delay, Jitter and PackLoss element. 
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6.3.49 Group 



<!ELEMENT Group ( GroupID?, Callld*, Sessionid*, (Amount, Unit)?, (ValidAfter, ValidUntil) ?, 

ValidUntil? )> 

<!ATTLIST Group critical (true I false) "true"> 

The Group element shall contain the group session's identifier in the Groupid element. The Group element shall 
contain at least one Sessionid or Callld element. The Group element shall contain at least one of the following 
parameter combinations: 

• Amount and Unit element to indicate a maximum number of calls; or 

• ValidAfter and ValidUntil element; or 

• ValidUntil element to indicate a maximum time period for calls. 



6.3.50 Groupid 



<! ELEMENT Groupid ( #PCDATA )> 

<!ATTLIST Groupid critical (true [ false) "true"> 

The Groupid element is used to identify one or more sessions (each uniquely identified by a Sessionid or 
Callld) crossing an inter-network interface. To convey its binary value, a session identifier may either be encoded 
using XML CD ATA format and appropriate escape sequences, or it may be encoded with base64 encoding as per 
the [4] standard. An encoding attribute indicates the method selected, and the default value for that attribute is XML 
CDATA. 

6.3.51 Sessionid 



< 


! ELEMENT 


Sessionid 


(#PCDATA)> 










< 


lATTLIST 


Sessionid 


encoding (cdat 


a 


1 base 


64) 


"cdat a" 






critical (true | 


fa 


Ise) 


"t 


rue"> 



The Sessionid element is used to uniquely identify individual sessions. To convey its binary value, a session 
identifier may either be encoded using XML CDATA format and appropriate escape sequences, or it may be encoded 
with base64 encoding as per the [4] standard. An encoding attribute indicates the method selected, and the default value 
for that attribute is XML CDATA. CalllD may be utilized in place of SessionID for H.323 sessions (calls). 

6.3.52 MultiSessionld 

<!ELEMENT MultiSessionld (MSId, Callld*, Sessionid*) > 
<!ATTLIST MultiSessionld encoding (cdata I base64) "cdata" 
critical (true | false) "true"> 

The MultiSessionld element shall contain the multi-session call's identifier in the MSId element. The 
MultiSessionld element shall contain at least one Sessionid or Callld element. 

6.3.53 MSId 



<! ELEMENT MSId (#PCDATA)> 






<!ATTLIST MSId encoding (cdata 


base64) 


"cdata" 


critical (true 


false) 


"true"> 



The MSId element is used to identify one or more sessions (each uniquely identified by a Sessionid or Callld) 
associated with a user or terminal. To convey its binary value, a session identifier may either be encoded using XML 
CDATA format and appropriate escape sequences, or it may be encoded with base64 encoding as per the [4] standard. 
An encoding attribute indicates the method selected, and the default value for that attribute is XML CDATA. 
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6.3.54 Contactid 

<!ELEMENT Contactid (#PCDATA)> 

<!ATTLIST Contactid critical (true I false) "true"> 

The Contactid element is not yet specified by TIPHON. The Contactid element is an operator-defined string 
which could identify either service provider or administrative zones. 



6.3.55 ServiceType 



<!ELEMENT ServiceType (#PCDATA) > 
<!ATTLIST ServiceType type ( voice | video) 

critical (true 1 false) #FIXED "false" > 

voice 
video 

The ServiceType element indicates the requested type of service (e.g. voice or video). 



Signature format 



If present, the digital signature within OSP shall conform to the application/pkcs7-signature format specified in the 
Secure Multipurpose Internet Mail Extensions (S/MIME) standard [17]. This clause specifies how that signature is 
created, including the canonicalization procedure, signature algorithm, and transfer encoding. 

7.1 Canonical form 

Digital signatures described in the present document are signatures of the entire, transmitted XML document, beginning 
with (and including) the leftmost "<" of the XML declaration and ending with (and including) the rightmost ">" of the 
end tag of the root XML entity. Furthermore, conforming implementations should construct their XML documents 
using the following procedures to arrive at a canonical form. Such a form will enable the reconstruction of an XML 
document (and the verification of a digital signature) from the abstract information of the document. 

NOTE 1 : The following procedure borrows heavily from the Internet Open Trading Protocol (IOTP) 
specification [24]. 

1) Isolate the element to be signed. For the present document, this consists of the entire XML document, 
beginning with the leftmost "<" of the XML declaration and ending with (and including) the rightmost ">" of 
the end tag of the root XML entity; 

2) convert all characters in the element to canonical form for the character encoding; 

3) apply all external XML entities and all character and entity references in the element so that they are 
completely resolved; 

4) exclude comments and processing instructions; 

5) reduce all attributes to their canonical form using the attribute type in the Document Type Definition (DTD). 
Replace all single and double quotes present in attributes with &#3 9; and " respectively so that attributes 
can be enclosed in double quotes; 

6) create attributes, using their default value, which are not present in the original but have default values in the 
DTD; 

7) sort the original and generated attributes in ascending attribute name order according to character encoding of 
the attribute name; 

8) for whitespace inside markup but not inside attribute values, generate it as minimally as possible. Specifically, 
(1) remove non-essential whitespace, and (2) represent required whitespace by a single space character; 
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9) generate the content of all start tags using only the element name and the attributes as described above. If the 
element is an empty element, then generate it using the single empty tag format (i.e. a trailing slash). Generate 
end tags using only element name with no added whitespace; 

10) remove all whitespace in the element content; 

11) assemble start tags, end tags, empty tags, CD ATA clauses, and text clauses in the same order as the original 
document. 

NOTE 2: The above procedure results in a canonicalized XML document rather than a canonicalized MIME text 
part. In particular, the line ending is encoded as a single line-feed character (#xA) rather than the 
S/MIME convention of a return/line-feed pair. 



7.2 Signature algorithms 



Annex B provides a list of cryptographic algorithms required and recommended by the present document, including 
S/MIME signature algorithms. 



7.3 Transfer encoding 



Unlike some electronic mail protocols, HTTP is capable of transferring raw binary data. Consequently, no transfer 
encoding (e.g. quoted-printable or base-64) shall be used for the signature. 



8 Protocol behaviour 

This clause specifies the relationship between the OSP message components. It defines message sequencing 
interdependence of messages, and exception handling. 



8.1 Message sequencing 



The present document specifies a simple client/server protocol. All protocol exchanges shall be initiated by clients, who 
send one or more of the eight client components in a single message. The server shall reply with its own single message, 
which contains one server component for each client component. Figure 4 shows the seven different component pairs. 

When multiple components are combined in a single message, each component shall be treated independently of all 
others in the message. Logically, this treatment shall have the same effect as if each component is carried in its own 

message. 

In addition, each component exchange shall be considered independent of all others; there shall be no dependence 
between message exchanges. This is true even of Authorization exchanges. Specifically, both 
Authorizationlndication/Confirmation and ReauthorizationRequest/Response exchanges may refer to authorization 
previously obtained through means other than an AuthorizationRequest and AuthorizationResponse. 

8.2 Exception handling 

If the OSP server cannot accept the authorization request because: 

• OSP client A or OSP Proxy cannot be authenticated, then the OSP server shall send an 

<AuthorizationResponse> component containing a «Code» element indicating "401 unauthorized (user 
authentication failed)". 



• 



• 



No routes can be returned, then the OSP server shall send an <AuthorizationResponse> component containing 
a «Code» element indicating "404 not found (no route to destination)". 

The source may not originate the call to the destination, then the OSP server shall send an 
<AuthorizationResponse> component containing a «Code» element indicating "405 source may not 
originate call to destination". 
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• The Sourcelnfo is invalid or missing, then the OSP server shall send an <AuthorizationResponse> component 
containing a «Code» element indicating "428 Sourcelnfo invalid or missing". 

• The route is known but not available, then the OSP server shall send an <AuthorizationResponse> component 
containing a «Code» element indicating "447 resource unavailable (route to destination may not 
terminate)". 

• The requested QoS cannot be granted, then the OSP server shall send an <AuthorizationResponse> component 
containing a «Code» element indicating "449 quality of service unavailable" and containing a 
«Service/QualityOfService» element indicating the highest level of QoS available. 

• The routes suggested by OSP client A or OSP Proxy are unknown, then the OSP server shall send an 
<AuthorizationResponse> component containing a «Code» element indicating "450 requested facility is not 
subscribed". 

• The requested service cannot be granted, then the OSP server shall send an <AuthorizationResponse> 
component containing a «Code» element indicating "463 service or option not available". 

• Requested group call cannot be granted, then the OSP server shall send an <AuthorizationResponse> 
component containing a «Code» element indicating "463 service or option not available" and containing a 
«Group» element indicating the quantity or duration available on a group call basis. 

• Source and destination are incompatible, then the OSP server shall send an <AuthorizationResponse> 
component containing a «Code» element indicating "488 incompatible destinations". 

If the OSP server cannot accept a request because: 

• Of malformed syntax, then the OSP server shall send a response containing a «Code» element indicating 
"400 bad request". 

• OSP client A or OSP Proxy is required to pay, then the OSP server shall send a response containing a 
«Code» element indicating "402 payment required". 

• The route is blocked for OSP client A or OSP Proxy, then the OSP server shall send a response containing a 
«Code» element indicating "403 route blocked". 

• Of decoding errors, then the OSP server shall send a response containing a «Code» element indicating 
"410 character encoding not supported". 

• Of parsing errors, then the OSP server shall send a response containing a «Code» element indicating 
"411 parsing unsuccessful". 

• Of an unsupported critical element, then the OSP server shall send a response containing a «Code» element 
indicating "412 critical element not supported". 

• Of a security problem, then the OSP server shall send a response containing a «Code» element indicating 
"420 generic security problem (no other information available)". 

• Of an invalid signature, then the OSP server shall send a response containing a «Code» element indicating 
"421 signature invalid". 

• Of an unsupported crypthographic algorithm, then the OSP server shall send a response containing a 
«Code» element indicating "422 cryptographic algorithm not supported". 

• Of an invalid certificate, then the OSP server shall send a response containing a «Code» element indicating 
"423 certificate invalid". 

• Of an revoked certificate, then the OSP server shall send a response containing a «Code» element 
indicating "424 certificate revoked". 

• Encryption is required, then the OSP server shall send a response containing a «Code» element indicating 
"425 encryption required". 

• Of a temporary failure, then the OSP server shall send a response containing a «Code» element indicating 
"441 temporary failure". 
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• Transactionid or Callld does not match any existing Transcationid or Callld, then the OSP server shall send a 
response containing a «Code» element indicating "481 callld invalid or missing". 

• The value of the «Timestamp» element is wrong, then the OSP server shall send a response containing a 
«Code» element indicating "495 invalid message". 

• It is not valid in a certain state, then the OSP server shall send a response containing a «Code» element 
indicating "495 invalid message". 

8.2.1 Transmission Control Protocol (TCP) 

If TCP indicates that communication cannot be established, or that communication has failed during a transmission, the 
communicating parties should not assume the delivery of any partial information. 

8.2.2 Secure Socket Layer (SSL)/Transport Layer Security (TLS) 

If SSL or TLS indicates that compatible encryption parameters cannot be established, the communicating parties should 
not assume the delivery of any partial information. In addition, if SSL/TLS is unable to successfully authenticate the 
server, the client should not proceed with the transfer of any information. 

8.2.3 Hypertext Transfer Protocol 

Communicating parties should treat HTTP status codes as defined in RFC 1945 [1]. In particular, unless the status code 
is in the range 200-299, the client should not assume delivery of any information. 
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Figure 4: Component pairs 

8.2.4 status element 

XML Code elements within responses and confirmations should be treated appropriately according to the definitions of 
clause 6.3.3. The associated Description element should be used solely for informational purposes. 



8.3 Transaction types 



Transactions may be completed by sending messages containing components on a: 

• per-session (per-call) basis: 

the message exchange is related to a single call with a unique call identifier or a single session with a session 
identifier. 

• group basis: 

in a group transaction an authorization token will be given for a specified number of calls between two 
domains or for a specified duration between two domains. Each call shall contain a common group identifier 
and one or more unique session or call identifiers. 

• multi session basis: 

the multi session is an aggregation of session and/or calls and sessions associated with a user or terminal. It 
shall contain one or more sessions or calls. 
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8.3.1 Group behaviour 



As shown in figure 4a, the OSP client requests authorization of a group. No Groupid is used because the OSP server 
manages the Groupid. 

Alternative 1 : The requested group is granted. The OSP client can now place calls by using the same group 
identifier. 

Alternative 2: The requested group cannot be granted (group failure). The OSP server indicates the available 
quantity or duration in a new Group element. No group identifier is returned because the new 
group does not yet exist. The new group will be created, if the OSP clients request authorization 
for the new group. 

Alternative 3: The requested group cannot be granted (group failure). The OSP server indicates the available 
quantity or duration in a new Group element. A group identifier is returned because this group 
does already exist (invitation to join a group). The OSP client will join this group, if it requests 
authorization for this group. Only in this case the AuthorizationReuqest will contain a Group 
element with Groupid. 

NOTE 1: Rather than granting 1000 calls for one group, the OSP server could grant 500 calls for group 1 and 
500 calls for group2. 

NOTE 2: The group feature implies that the terminating gatekeeper is capable of counting the number of inbound 
calls. 

NOTE 3: For group calls the token is calculated using the Groupid, not the Callld or Sessionld. 
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Figure 4a: Group request 1 

As shown in figure 4b, the OSP client requests authorization of a single call. 
Alternative 1 : The requested call is granted. 
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Alternative 2: The requested call is granted. If the OSP server wishes to invite a single call to a group, then a 
Group element should be included. No group identifier is returned because the new group does 
not yet exist. The new group will be created, if the OSP clients request authorization for the new 
group. 

Alternative 3: The requested call is granted. If the OSP server wishes to invite a single call to a group, then a 

Group element should be included. A group identifier is returned because this group does already 
exist (invitation to join a group). The OSP client will join this group, if it requests authorization for 
this group. 
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Figure 4b: Call request 1 



8.3.2 Group identifiers 



Figure 4c shows a possible implementation of group identifiers. A multi media call (MultiSessionld 1) could consist of 
multiple H.323 calls (Callld 1, 2, 3) and multiple SIP sessions (Sessionid 1,2). The border proxy could map this multi 
media call to different groups. Within group 2 (Groupid 2) a H.323 call would be identified by its multi media call 
identifier (MSId 1) and its H.323 call identifier (Callld 1). Even different multi media calls could be mapped to group 2. 
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Figure 4c: Group identifiers 
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Annex A (normative): 
Document Type Definition (DTD) 



This annex contains the complete XML document type definition for the messages described in the present document. 
The information is repeated from clause 6 and annex C, but is collected in one place for convenience of reference. 

<!ELEMENT Message ( ( Pricinglndication | PricingConf irmation | AuthorizationRequest I 
AuthorizationResponse 1 Authorizationlndication | AuthorizationConf irmation | Usagelndication | 
UsageConf irmation | ReauthorizationRequest 1 ReauthorizationResponse 1 

SubscriberAuthenticationRequest I SubscriberAuthenticationResponse 1 Capabilitieslndication | 
CapabilitiesConf irmation )+ )> 
<!ATTLIST Message messageld ID #REQUIRED 

random CDATA #REQUIRED> 
<!ELEMENT Pricinglndication ( Timestamp, Sourcelnfo, Destinationlnfo, Currency, Amount, Increment, 
Unit, Service, ValidAfter, ValidUntil )> 
<!ATTLIST Pricinglndication componentid ID #REQUIRED> 
<! ELEMENT PricingConf irmation ( Timestamp, Status )> 
<!ATTLIST PricingConf irmation componentid ID #REQUIRED> 

<!ELEMENT AuthorizationRequest ( Timestamp, Callld*, Sourcelnfo, SourceAlternate*, Destinationlnfo, 
DestinationAlternate*, Service, MaximumDestinations, Token*, SubscriberAuthenticationlnfo* , 
Sessionid*, MultiSessionld*, Group* )> 

<!ATTLIST AuthorizationRequest componentid ID #REQUIRED> 

<!ELEMENT AuthorizationResponse ( Timestamp, Status, Transactionid, Token*, Destination*, Service?, 
Group* ) > 

<!ATTLIST AuthorizationResponse componentid ID #REQUIRED> 

<!ELEMENT Authorizationlndication ( Timestamp, Role, Callld, Sourcelnfo, SourceAlternate*, 
Destinationlnfo, DestinationAlternate*, Service, Token* )> 
<!ATTLIST Authorizationlndication componentid ID #REQUIRED> 

<!ELEMENT AuthorizationConf irmation ( Timestamp, Status, ValidAfter, ValidUntil )> 
<!ATTLIST AuthorizationConf irmation componentid ID #REQUIRED> 

<!ELEMENT Usagelndication ( Timestamp, Role, Transactionid, Callld, Sourcelnfo, SourceAlternate*, 
Destinationlnfo, DestinationAlternate*, UsageDetail*) > 
<!ATTLIST Usagelndication componentid ID #REQUIRED> 
<! ELEMENT UsageConf irmation ( Timestamp, Status )> 
<!ATTLIST UsageConf irmation componentid ID #REQUIRED> 

<!ELEMENT ReauthorizationRequest ( Timestamp, Role, Callld, Sourcelnfo?, SourceAlternate*, 
Destinationlnfo?, DestinationAlternate*, Transactionid, UsageDetail*, Token* )> 
<!ATTLIST ReauthorizationRequest componentid ID #REQUIRED> 

<!ELEMENT ReauthorizationResponse ( Timestamp, Status, Transactionid, Token*, Destination* )> 
<!ATTLIST ReauthorizationResponse componentid ID #REQUIRED> 

<!ELEMENT SubscriberAuthenticat lonRequest (Timestamp, Sourcelnfo, SourceAlternate*, 
Destinationlnfo?, Service?) > 

<!ATTLIST SubscriberAuthenticationRequest componentid ID #REQUIRED> 

<!ELEMENT SubscriberAuthent icat lonResponse (Timestamp, Status, SubscriberAuthenticationlnfo*) > 
<!ATTLIST SubscriberAuthenticationResponse componentid ID #REQUIRED> 

<!ELEMENT Capabilitieslndication (Devicelnfo*, OSPVersion, OSPCapability*, Resources*) > 
<!ATTLIST Capabilitieslndication componentid ID #REQUIRED 

critical ( true I false ) #FIXED "false"> 
<!ELEMENT CapabilitiesConf irmation (Timestamp, Status, OSPVersion, OSPService*, Certif icateChain*, 
Deviceld?) > 
<!ATTLIST CapabilitiesConf irmation componentid ID #REQUIRED 

critical (true I false) #FIXED "false"> 
<! ELEMENT Amount (#PCDATA)> 

<!ATTLIST Amount critical (true | false) "true"> 
<! ELEMENT AuthorityURL (#PCDATA)> 

<!ATTLIST AuthorityURL critical (true | false) "true"> 
<!ELEMENT Callld (#PCDATA)> 
<!ATTLIST Callld encoding (cdata 1 base64) "cdata" 

critical (true 1 false) "true"> 
<! ELEMENT Code (#PCDATA)> 

<!ATTLIST Code critical (true I false) "true"> 
<! ELEMENT Currency (#PCDATA)> 

<!ATTLIST Currency critical (true | false) "true"> 
ELEMENT Description (#PCDATA)> 

ATTLIST Description critical (true \ false) "false"> 

ELEMENT Destination ( Destinationlnfo?, DestinationAlternate*, DestinationSignalAddress, Token*, 
ValidAfter?, ValidUntil?, UsageDetail*, AuthorityURL*, DestinationProtocol?, Callld*, , Sessionid*, 
MultiSessionld*, Group* )> 

<! ATTLIST Destination critical (true 1 false) "true"> 
<!ELEMENT DestinationAlternate (#PCDATA)> 

<! ATTLIST DestinationAlternate type ( el64 t h323 I url [ email I transport 1 international I 
national I network | subscriber | abbreviated I el64prefix ) #REQUIRED 

critical ( true | false ) "true" > 
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<!ELEMENT Dest inat ioninf o (#PCDATA)> 

<!ATTLIST Destinationinf o type ( el64 1 h323 1 url | email 1 transport 1 international 1 national I 

network | subscriber | abbreviated 1 el64prefix ) #REQUIRED 

critical ( true | false ) "true" > 
<!ELEMENT Dest inat ionSignalAddress (#PCDATA)> 

<!ATTLIST DestinationSignalAddress critical (true | false) "true"> 
<! ELEMENT Increment (#PCDATA)> 

<!ATTLIST Increment critical (true I false) "true"> 
<!ELEMENT MaximumDest inat ions (#PCDATA)> 

<!ATTLIST MaximumDestinations critical (true 1 false) "true"> 
<! ELEMENT Role (#PCDATA)> 

<!ATTLIST Role critical (true I false) "true"> 

<!ELEMENT Service ( ServiceType?, Bandwidth?, QualityOf Service? )> 
<!ATTLIST Service critical (true | false) "true"> 
<!ELEMENT SourceAlternate (#PCDATA)> 

<!ATTLIST SourceAlternate type ( el64 | h323 1 url 1 email I transport I international 1 national I 
network | subscriber | abbreviated I el64prefix | iso7812 | pin | epin | deviceld ) #REQUIRED 

critical ( true | false ) "true" > 
<!ELEMENT Sourcelnfo (#PCDATA)> 

<!ATTLIST Sourcelnfo type ( el64 | h323 I url | email 1 transport I international I national I 
network | subscriber | abbreviated 1 el64prefix | iso7812 | pin 1 epin | deviceld ) #REQUIRED 

critical ( true 1 false ) "true" > 
<!ELEMENT SourceSignalAddress (#PCDATA)> 

<!ATTLIST SourceSignalAddress critical (true I false) "true"> 
<!ELEMENT Status ( Code, Description? )> 
<!ATTLIST Status critical (true | false) "true"> 
<! ELEMENT Timestamp (#PCDATA)> 

<!ATTLIST Timestamp critical (true I false) "true"> 
<! ELEMENT Token (#PCDATA)> 
<!ATTLIST Token encoding (cdata I base64) "cdata" 

critical (true | false) "true"> 
<!ELEMENT Transact ionid (#PCDATA)> 

<!ATTLIST Transactionid critical (true \ false) "true"> 
<! ELEMENT Unit (#PCDATA)> 

<!ATTLIST Unit critical (true | false) "true"> 

<!ELEMENT UsageDetail (Service, Amount, Increment, Unit, StartTime?, EndTime?, TerminationCause?, 
Statistics? )> 

<!ATTLIST UsageDetail critical (true | false) "true"> 
<! ELEMENT ValidAfter (#PCDATA)> 

<!ATTLIST ValidAfter critical (true | false) "true"> 
<!ELEMENT ValidUntil (#PCDATA)> 

<!ATTLIST ValidUntil critical (true I false) "true"> 
<! ELEMENT EndTime (#PCDATA)> 

<!ATTLIST EndTime critical (true 1 false) #FIXED "false"> 
<! ELEMENT StartTime (#PCDATA)> 

<!ATTLIST StartTime critical (true | false) #FIXED "false"> 
<! ELEMENT TCCode (#PCDATA)> 

<!ATTLIST TCCode critical (true | false) #FIXED "false"> 
<!ELEMENT TerminationCause (TCCode, Description? ) > 

<!ATTLIST TerminationCause critical (true | false) #FIXED "false"> 
<!ELEMENT Certificate (#PCDATA)> 
<!ATTLIST Certificate encoding (cdata I base64) "base64" 

critical (true | false) #FIXED "false"> 
<!ELEMENT Cert if icateChain (Certificate* ) > 

<!ATTLIST Certif icateChain critical (true I false) #FIXED "false"> 
<!ELEMENT OSPCapability (#PCDATA)> 

<!ATTLIST OSPCapability critical (true | false) #FIXED "false"> 
<!ELEMENT OSPService (OSPCapability, OSPServiceURL*, OSPSignatureRequired) > 
<!ATTLIST OSPService critical (true I false) #FIXED "false"> 
<!ELEMENT OSPServiceURL (#PCDATA)> 

<!ATTLIST OSPServiceURL critical (true 1 false) #FIXED "false"> 
<!ELEMENT OSPSignatureRequired (#PCDATA)> 

<!ATTLIST OSPSignatureRequired critical (true [ false) #FIXED "false"> 
<!ELEMENT OSPVersion (#PCDATA)> 

<!ATTLIST OSPVersion critical (true I false) #FIXED "false"> 
<!ELEMENT SubscriberAuthenticat ioninf o (#PCDATA)> 
<!ATTLIST SubscriberAuthenticationInf o encoding (cdata I base64) "cdata" 

critical (true | false) #FIXED "false"> 
<!ELEMENT Devicelnfo (#PCDATA) > 

<!ATTLIST Devicelnfo type ( el64 1 h323 I url | email t transport I serialnumber | customerld ) 
♦REQUIRED 

critical ( true 1 false ) #FIXED "false" > 
<!ELEMENT Deviceld (#PCDATA) > 

<!ATTLIST Deviceld critical (true | false) "false" > 
<!ELEMENT Resources ( DataRate?, AlmostOutOfResources? ) > 
<!ATTLIST Resources critical ( true I false ) #FIXED "false" > 
<! ELEMENT DataRate ( NumberOf Channels?, Bandwidth ) > 
<!ATTLIST DataRate critical ( true | false ) #FIXED "false" > 
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ELEMENT NumberOf Channels (tPCDATA) > 

ATTLIST NumberOfChannels critical (true | false) #FIXED "false" > 

ELEMENT Bandwidth (tPCDATA) > 

ATTLIST Bandwidth critical (true 1 false) #FIXED "false" > 

ELEMENT AlmostOutOf Resources (#PCDATA) > 

ATTLIST AlmostOutOfResources critical (true \ false) #FIXED "false" > 

ELEMENT Statistics ( LossSent?, LossReceived?, OneWayDelay?, RoundTripDelay?, Delay?, Jitter?, 
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ATTLIST Statistics critical (true | false) #FIXED "false"> 

ELEMENT LossSent ( Packets, Fraction )> 

ATTLIST LossSent critical (true | false) #FIXED "false"> 

ELEMENT Packets (#PCDATA)> 

ATTLIST Packets critical (true | false) #FIXED "false"> 

ELEMENT Fraction (#PCDATA)> 

ATTLIST Fraction critical (true | false) #FIXED "false"> 

ELEMENT LossReceived ( Packets, Fraction )> 

ATTLIST LossReceived critical (true I false) #FIXED "false"> 

ELEMENT OneWayDelay ( Minimum, Mean, Variance, Samples ) > 

ATTLIST OneWayDelay critical (true | false) #FIXED "false"> 

ELEMENT Minimum (#PCDATA)> 

ATTLIST Minimum critical (true 1 false) #FIXED "false"> 

ELEMENT Maximum (#PCDATA)> 

ATTLIST Maximum critical (true | false) #FIXED "false"> 

ELEMENT Mean (#PCDATA)> 

ATTLIST Mean critical (true I false) #FIXED "false"> 

ELEMENT Variance (#PCDATA)> 

ATTLIST Variance critical (true | false) #FIXED "false"> 

ELEMENT Samples (#PCDATA)> 

ATTLIST Samples critical (true 1 false) #FIXED "false"> 

ELEMENT RoundTripDelay ( Minimum, Mean, Variance, Samples ) > 

ATTLIST RoundTripDelay critical (true I false) #FIXED "false"> 

ELEMENT Dest inat ionProtocol (#PCDATA) > 

ATTLIST DestinationProtocol critical ( true 1 false ) #FIXED "false"> 

ELEMENT ServiceType (#PCDATA)> 

ATTLIST ServiceType critical (true i false) "true"> 

ELEMENT QualityOf Service (QoSClass? I QoSParameters? ) > 

ATTLIST QualityOfService critical (true | false) "true"> 

ELEMENT QoSClass (#PCDATA)> 

ATTLIST QoSClass critical (true | false) "true"> 

ELEMENT QoSParameters (Delay, Jitter, PackLoss) > 

ATTLIST QoSParameters critical (true ( false) "true"> 

ELEMENT Delay (Minimum?, Mean?, Maximum?, Variance?, Samples?) > 

ATTLIST Delay critical (true 1 false) "true"> 

ELEMENT Jitter (Minimum?, Mean?, Maximum?, Variance?, Samples?) > 

ATTLIST Jitter critical (true | false) "true"> 

ELEMENT PackLoss (Minimum?, Mean?, Maximum?, Variance?, Samples?) > 

ATTLIST PackLoss critical (true 1 false) "true"> 

ELEMENT Group (GroupId?, (Amount, Unit)?, (ValidAfter, ValidUntil) ?, ValidUntil? )> 

ATTLIST Group critical (true I false) "true"> 

ELEMENT GroupId (#PCDATA)> 

ATTLIST GroupId critical (true I false) "true"> 

ELEMENT Sessionid (#PCDATA)> 

ATTLIST Sessionid critical (true | false) "true"> 

ELEMENT Mult iSessionId (MSId, Callld+, Sessionid! )> 

ATTLIST MultiSessionld critical (true t false) "true"> 

ELEMENT MSId (MSId, Callld+, Sessionid! )> 

ATTLIST MSId critical (true | false) "true"> 
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Annex B (normative): 
Cryptographic Algorithms 



For convenience and ease of reference, this annex provides the specification of cryptographic algorithms referenced in 
the standard. Cryptographic algorithms are essential to SSL/TLS communications, S/MIME signatures, and token 
formats. 



B.1 SSL/TLS CipherSuites 



Systems conforming to the present document may negotiate any mutually supported SSL/TLS CipherSuite using the 
standard SSL/TLS handshake mechanisms. To ensure maximum interoperability, all compliant systems should support 
the SSL_RSA_WITH_3DES_EDE_CBC_SHA CipherSuite. In environments where triple DES data encryption is not 
desired or is otherwise unavailable, systems should support the SSL_RSA_EXPORT_WITH_DES40_CBC_SHA 
CipherSuite. If no data encryption is desired or available, systems should use the SSL_RSA _WITH_NULL_SHA 
CipherSuite. 



B.2 S/IVIIIVIE signatures 



Communicating systems may use any digest and signing algorithms defined by the S/MIME standard [17]. To ensure 
interoperability, all compliant systems shall support the Secure Hash Algorithm (SHA) [16] for message digests, and 
the Digital Signature Algorithm (DSA) [15] for signing. 

NOTE: To take maximum advantage of deployed cryptographic software, systems should also support the 
Message Digest 5 (MD5) digest algorithm [19] and the Rivest Shamir Adleman (RSA) signature 
algorithm [20]. 



B.3 Tokens 



Tokens used for authorization, call progress, and call completion may be signed and encrypted. For message digest, 
signing, and encryption, implementations may use any algorithm defined by the Public Key Cryptography 
Standard #7 (PKCS7) [21]. To ensure interoperability, systems should support Secure Hash Algorithm [16], 
Diffie-Hellman key exchange (see bibliography). Digital Signature Algorithm [15], and the Data Encryption 
Standard [15]. 

NOTE: To take maximum advantage of deployed cryptographic software, systems should also support the 
Message Digest 5 [19], Rivest Shamir Aldeman [20], and Rivest Cipher 2 [18] algorithms. 
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Annex C (normative): 
Enhanced usage reports 



The following optional Enhanced Usage elements may be added to the UsageDetail element of Usagelndication 

messages. 

C.1 Enhanced usage elements 

The definition of Enhanced Usage elements, and the definition of sub-elements, follows. 

C.1.1 statistics 

<!ELEMENT Statistics ( LossSent?, LossReceived?, OneWayDelay?, RoundTripDelay?, Delay?, Jitter?, 

PackLoss? )> 

<!ATTLIST Statistics critical (true 1 false) #FIXED "false"> 

The Statistics element collects network performance statistics for the call. It may include packet loss statistics (in 
either direction) and delay statistics (one-way or round trip.) The entire element is non-critical, and may thus be safely 
ignored by systems that do not support it. 

C.1.2 LossSent 

<!ELEMENT LossSent ( Packets, Fraction )> 

<!ATTLIST LossSent critical (true 1 false) #FIXED "false"> 

The LossSent element contains packet loss information for datagrams transmitted by the reporting system that were 
not received by its peer, as reported in the peer's RTCP sender and receiver reports. It includes the two sub-elements 
described in clauses C.1.3 and CIA. 

C.1.3 Packets 

<!ELEMENT Packets (#PCDATA)> 

<!ATTLIST Packets critical (true \ false) #FIXED "false"> 

The Packets element contains a count of the total number of packets. The value is formatted as a decimal number 
without punctuation. 

C.1.4 Fraction 

<!ELEMENT Fraction (#PCDATA)> 

<!ATTLIST Fraction critical (true I false) #FIXED "false"> 

The Fraction element contains a value for a fraction of packets, expressed as an integer number from (no packets) 
to 255 (all packets), and it is formatted as a decimal number without punctuation. 



C.1.5 LossReceived 



<!ELEMENT LossReceived ( Packets, Fraction )> 

<!ATTLIST LossReceived critical (true | false) #FIXED "false"> 

The LossReceived element contains packet loss information for datagrams that should have been received by the 
reporting system receive but were not, as reported in the system's RTCP sender and receiver reports. It includes the two 
sub-elements "packets" and "fraction" described in clauses C.1.3 to C.1.4. 



£75/ 



48 ETSI TS 101 321 V4.1.1 (2003-11) 



C.1.6 OneWayDelay 



<! ELEMENT OneWayDelay ( Minimum, Mean, Variance, Samples )> 
<!ATTLIST OneWayDelay critical (true I false) #FIXED "false"> 

The OneWayDelay element reports measurements of one way delay to the reporting system/ro»i its peer, as measured 
during the communication. It is suggested that the measurement be made by comparing the network time protocol 
(NTP) timestamp included in RTCP messages sent by the peer with the local NTP time. The element consists of the 
following four sub-elements. 



C.1.7 Minimum 



<! ELEMENT Minimum (#PCDATA)> 

<!ATTLIST Minimum critical (true I false) #FIXED "false"> 

The Minimum element reports the minimum measured value, expressed in milliseconds. It is formatted as an 
integer decimal number without punctuation. 



C.1.8 Mean 

<! ELEMENT Mean (#PCDATA)> 

<!ATTLIST Mean critical (true 1 false) #FIXED "false"> 

The Mean element reports the statistical mean of all measured values. It is expressed in milliseconds, and it is formatted 
as an integer decimal number without punctuation. 

C.1.9 Variance 

<!ELEMENT Variance (#PCDATA)> 

<!ATTLIST Variance critical (true I false) #FIXED "false"> 

The Variance element reports the statistical variance of all measured values. It is expressed in squared milliseconds, 
and it is formatted as an integer decimal number without punctuation. 



C.1.10 Samples 



<! ELEMENT Samples (#PCDATA)> 

<!ATTLIST Samples critical (true I false) #FIXED "false"> 

The Samples element reports the number of samples measured by the reporting system. It is formatted as a decimal 
number without punctuation. 



C.1.11 RounclTripDelay 



<! ELEMENT RoundTripDelay ( Minimum, Mean, Variance, Samples )> 
<!ATTLIST RoundTripDelay critical (true | false) #FIXED "false"> 

The RoundTripDelay element reports measurements of round trip delay between the reporting system and its peer, 
as measured during the communication. Such measurements may be made, for example, by 
ITU-T Recommendation H.245 [9] round trip delay exchanges during the call. The element consists of the four 
sub-elements described above. 



C.1.12 Maximum 



<! ELEMENT Maximum (#PCDATA)> 

<!ATTLIST Maximum critical (true I false) #FIXED "false"> 

The Maximum element reports the maximum measured value, expressed in milliseconds. It is formatted as an 
integer decimal number without punctuation. 



C.1.13 Delay 

<! ELEMENT Delay ( Min 

<!ATTLIST Delay critiucii j u^uc i j-cij-oc , u^uc ^ 

The Delay element requests or reports the delay of a packet. 



<!ELEMENT Delay ( Minimum?, Mean?, Maximum?, Variance?, Samples? ) > 
<!ATTLIST Delay critical ( true 1 false ) "true"> 
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<!ELEMENT Jitter ( Minimum?, Mean?, Maximum?, Variance?, Samples? ) > 
<!ATTLIST Jitter critical ( true I false ) "true"> 



C.1.14 Jitter 

<! ELEMENT Jitter ( I' 

<!ATTLIST Jitter critical ( true I talse ) "true"> 

The Jitter element requests or reports the jitter of a packet. 

C.1.15 PackLoss 

<! ELEMENT PackLoss ( Minimu 

<!ATTLIST PackLoss critical i true i -taxse ; ■■true 

The PackLoss element requests or reports the packet loss. 



<!ELEMENT PackLoss ( Minimum?, Mean?, Maximum?, Variance?, Samples? ) > 
<!ATTLIST PackLoss critical ( true I false ) "true"> 
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Annex D (informative): 
Token formats 



This annex presents suggested formats for authorization tokens included in the authorization information defined in the 
present document. Once obtained by an endpoint, such tokens may be passed as part of the call signalling exchange. 
The annex describes suggested cryptographic encodings as well as suggested contents for these authorization tokens, 
and it identifies methods for carrying tokens within call signalling protocols. Clause D.4 shows a complete, sample 
token. 



D.1 Cryptographic encoding 



Depending on the business roles and network environment, tokens may be digitally signed and/or encrypted. If digitally 
signed, tokens should conform to Cryptographic Message Syntax (CMS) specification [27] for signed-data content. If 
encrypted, tokens should conform to the CMS specification for enveloped-data content. If tokens are both signed and 
encrypted, they should be constructed in two phases. First, the token should be digitally signed, resulting in CMS 
signed-data content. The resulting signed content should then be encrypted, resulting in CMS enveloped-data content. 

If the token syntax and semantics are understood by all relevant parties, then authorization tokens may use the generic 
id-data OBJECT IDENTIFER (1.2.480.113549.1.7.1) as the data content type. If a token contents are consistent with 
one of the formats described in this annex, and if the token wishes to explicitly identify that format, it may use one of 
the following object identifiers as the data content type: 

• osp-token-contents-asnl OBJECT IDENTIFER ::= { itu-t(O) identified-organization(4) etsi(O) 
ts-101-321(1321)token-contents(2) 1 } 

• osp-token-contents-xml OBJECT IDENTIFER ::= { itu-t(O) identified-organization(4) etsi(O) 
ts-101-321(1321) token-contents(2) 2 } 

• osp-token-contents-bxml OBJECT IDENTIFER ::= { itu-t(O) identified-organization(4) etsi(O) 
ts-101-321(1321) token-contents(2) 3 } 

Annex B documents the cryptographic algorithms recommended by the present document, including digest, signing, 
symmetric encryption, and asymmetric encryption algorithms. 

To minimize the size of resulting tokens, appropriate certificates may be conveyed to endpoints as part of the 
Capabiiitiesconf irmaion message, and the Optional CMS CertificateSet information element may be omitted from 
individual tokens. In such cases, the most efficient way to identify the signer is to use the SubjectKeyldentifier, where 
its contents are a SHA-1 hash of the signer's public key. An example of such a token is: 

SignedData ::= SEQUENCE { 

version CMSVersion, version 3 

digestAlgorithms DigestAlgorithmldentifiers, e.g. md5 (1.2.840.113594.2.5) 

encapContentlnformation EncapsulatedContentlnfo, e.g. osp-token-contents-bxml 

signerlnfos Signerlnfos } see below 



Where, the Signerlnfos consists of the following single element: 

Signerlnfo ::= SEQUENCE { 

version CMSVersion, version 3 

sid Signerldentifier, see below 

digestAlgorithmDigestAlgorithmldentifier, e.g. md5 (1.2.840.113594.2.5) 

signatureAlgorithm SignatureAlgorithmldentifier, e.g. rsa (1.2.840.113594.1.1.1) 

signature SignatureValue } 128-octet signature 
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And the Signerldentifier element is: 



Signerldentifier ::= CHOICE { 

SubjectKeyldentifier [0] } 20-octet SHA-1 hash of signer's public key 

This encoding will result in a token whose size is about 250 octets plus the size of the signed contents. 

NOTE: The SubjectKeyldentifier element may be used even when the signer's public key certificate does not 

explicitly include that specific extended attribute, as the recipient will be able to compute the appropriate 
value from the certificate's public key. 



D.2 Token content 

This clause suggests two different token formats. The ASN.l format relies on information elements defined in the 
ITU-T Recommendation H.323 [12] standards, and is appropriate for native H.323 [12] systems. The XML format is 
consistent with the body of the present document, and may be used where ASN.l encoding/decoding is not available or 
desired. The Binary XML format is a more compact representation of the XML format. 

D.2.1 ASN.1 format 

The actual content of the token may conform to the following ASN. 1 specifications, as augmented by ASN. 1 constructs 
from the ITU-T Recommendation H.323 [12] standards [12], [8], [13], and [9]. The tokens should be encoded using the 
Packed Encoding Rules (Aligned) of ITU-T Recommendation X.691 [10]. 

ETSI-TIPHON-TOKENS DEFINITIONS AUTOMATIC TAGS ::= 

BEGIN 

IMPORTS 

AliasAddress, 
Callldentifier, 
ReleaseCompleteReason, 
TimeStamp 
FROM H323-MESSAGES; 
ServiceDescription : : = CHOICE 
{ 

basicTelephony NULL, 

ve ndor Specif ic NonStandardParameter, 

} 

MeasureUnits : : CHOICE 

{ 

seconds NULL, 

packets NULL, 

bytes NULL, 

ve ndor Specif ic NonStandardParameter, 

} 

UsageData : : = SEQUENCE 

{ 

amount INTEGER (0 .. 4294967295 )) , 

units MeasureUnits, 

increment INTEGER ( 1 .. 4294967295 ) , 

ve ndor Specif ic NonStandardParameter, 

} 

AuthorizationToken : : = SEQUENCE 

{ 

random INTEGER ( 1 .. 4294967295 ) , 

sourcelnfo SEQUENCE OF AliasAddress, 

destinationlnfo SEQUENCE OF AliasAddress, 

callld Callldentifier OPTIONAL, 

validAfter TimeStamp OPTIONAL, 

validUntil TimeStamp OPTIONAL, 

transactionid OCTET STRING (SIZE (16)) OPTIONAL, 

serviceAuthorized SEQUENCE OF SEQUENCE 

{ 

service ServiceDescription, 

limit UsageData OPTIONAL 

} OPTIONAL, 

authorityURL SEQUENCE OF IA5String (SIZE ( 1 .. 512 ) ) OPTIONAL, 
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vendorSpecif ic NonStandardParameter OPTIONAL, 

} 

END — of ASN. 1 

D.2.2 XML format 

Authorization tokens may also be constructed in XML as a standalone XML document. The root element of such a 
document shall be Tokeninf o, and it shall conform to the following construction: 

<!ELEMENT Tokenlnfo ( Sourcelnfo?, SourceAlternate*, Destinationinf o?, DestinationAlternate*, 
Callld*, ValidAfter?, ValidUntil?, Transactionid?, UsageDetail*, 
AuthorityURL*, Group?, MultiSessionld*, Sessionid* )> 

<!ATTLIST Tokenlnfo random #REQUIRED> 

The individual elements of the document, including any private or future extensions, shall conform to the body of the 
present document. The following text illustrates an example XML token: 

<TokenInfo random=" 12345678 "> 

<SourceInfo type="el64 ">81458811202</Sourcelnf o> 
<DestinationInfo type="el64 ">47 668413 60</Destinationlnf o> 
<CallId encoding=base64>Aadf9811asdfA8adooif7c3nnsa8 9</CallId> 
<ValidAfter>1998-04-24T17 : 01 : 01Z</ValidAfter> 
<ValidUntil>1998-04-24T17 : 11 : 01Z</ValidUntil> 
<TransactionId>67 7237 4</TransactionId> 
<UsageDetail> 

<Service/> 

<Amount>2 4 < /Amount > 

<Increment>3 600</Increment> 

<Unit>s</Unit> 
</UsageDetail> 
</TokenInfo> 



D.2.3 Binary XML format 



Binary XML (see annex H) provides a more compact representation of XML documents, and may be applied to 
authorization token contents. The contents of the token of clause D.2.2, when represented as Binary XML according to 
the rules of annex H, are as follows: 



02 01 03 00 

F6 OB 03 '12345678' 00 

EE OF 01 03 '81458811202' 00 01 
D6 OF 01 03 '4766841360' 00 01 
CD 8 01 03 

'Aadf9811asdfA8adooif7c3nnsa89' 00 01 
7D 03 '1998-04-24T17:01:01Z' 00 01 
7E 03 '1998-04-24T17:ll:01Z' 00 01 
78 03 '6772374' 00 01 



7E 



01 



2C 

46 03 '24' 00 01 

5C 03 '3600' 00 01 

79 03 's' 00 01 



01 



D.3 Token carriage 



When carried as part of a call signalling message of an ASN. 1-based protocol, authorization tokens may be identified 
by one of the following object identifiers. The first value is for tokens with self -identifying or otherwise unspecified 
formats. 

osp-token OBJECT IDENTIFER ::= { itu-t(O) identified-organization(4) etsi(O) ts-101-321(1321) token (1) } 

osp-token-asnl -format OBJECT IDENTIFER ::= { itu-t(O) identified-organization(4) etsi(O) ts-101-321(1321) 
token (1)1 } 

osp-token-xml-format OBJECT IDENTIFER ::= { itu-t(O) identified-organization(4) etsi(O) ts-101-321(1321) 
token(l) 2 } 
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osp-token-bxml-format OBJECT IDENTIFER ::= { itu-t(O) identified-organization(4) etsi(O) ts-101-321(1321) 
token(l) 3 } 

When carries as part of a call signalling message of a MIME-based protocol, authorization tokens may be identified by 
the following MIME type: 

MIME media type name: x-application 
MIME subtype name: x-osp-token 
Required parameters: none 
Optional parameters : 

x-osp-token-f ormat : a value of "asn.l" indicates the token contents use the ASN . 1 format 
defined in annex D, clause D.2.1 of the OSP specification; a value of "xml" indicates 
the token contents use the XML format defined in annex D, clause D.2.2 of the OSP 
specification, and a value of "bxml" indicates the token contents use the Binary XML 
format defined in annex D, clause D.2.3 of the OSP specification. In the absence of 
any value for this parameter, the token contents shall be self identifying or 
otherwise understood by appropriate parties . 
x-osp-token-version : a character string indicating the earliest revision of the OSP 

specification to which the token contents conform. In the absence of any value for 
this parameter, the token contents shall conform to version "2.1.1" of the OSP 
specification. 
Encoding considerations: OSP tokens are normally carried as binary data by the call 

signalling protocol. Call signalling protocols which cannot reliably transfer binary data 
may use alternate encodings such as base-64, in which case standard MIME content-encoding 
parameters may indicate the particular encoding. 
Security considerations: OSP tokens are intended to provide access control to resources of 
other administrative domains, and, as such, are inherently designed to address security 
concerns. For that reason, OSP tokens are digitally signed and, optionally, encrypted, as 
defined in the OSP specification. 
Interoperability considerations: The means and/or algorithms by which a receiving system 
determines whether or not an OSP token is valid are a local matter. However, at a 
minimum, receiving systems should verify the digital signature of the token, and they 
should ensure that any call details included in the token contents (e.g. called number, 
calling number, etc.) are appropriate for the contemplated call. 
Published specification: "Telecommunications and Internet Protocol Harmonization Over 
Networks (TIP HON) ; Open Settlement Protocol (OSP) for Inter-domain pricing, 
authorization, and usage exchange". Technical Specification 101 321. European 
Telecommunications Standards Institute. Version 2.1.1 
Applications which use this media type: IP telephony call signalling protocols that use MIME 

types to convey additional information during call setup. 
Additional information : 

Magic number (s) : none 
File extension (s) : none 
Macintosh File Type Code(s) : none 
Person & email address to contact for further information: Stephen Thomas, 

Stephen . thomas@ trans nexus . com 
Intended usage: COMMON 
Author/Change controller: European Telecommunications Standards Institute 

NOTE: A corresponding MIME type of osp-token may be registered with lANA. 
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D.4 Sample token 



30 82 


01 


Al 


SEQUENCE (len = 


417) 


06 09 






OBJECT IDENTIFIER = 1.2.840.113594.1.7.2 (id-signedData) 


AO 82 


01 


92 


EXPLICIT TAG [0] (len = 402) 


30 82 


01 


8E 


SEQUENCE (len = 398) 


02 01 


03 




INTEGER = 3 (version) 


31 OE 






SET 


(len = 14) 


30 OC 








SEQUENCE (len = 12) 


06 08 








OBJECT IDENTIFER = 1.2.840.113594.2.5 (md5) 


05 00 








NULL 


30 82 


00 


B3 


SEQUENCE (len = 179) 


06 06 








OBJECT IDENTIFIER = 0.4.0.1321.2.3 (osp-token-contents-bxml) 


AO 82 


00 


AB 




EXPLICIT TAG [0] (len = 171) 


04 82 


00 


A7 




OCTET STRING (len = 167) 


02 01 


03 


00 




token contents 


31 82 


00 


CO 


SET 


(len = 192) 


30 82 


00 


EC 




SEQUENCE (len = 188) 


02 01 


03 






INTEGER = 3 (version) 


AO 16 








EXPLICIT TAG [0] 


04 14 








OCTET STRING (len = 20) 

SHA-1 hash of signer's public key information 


30 OC 








SEQUENCE (len = 12) 


06 08 








OBJECT IDENTIFIER = 1.2.840.113594.2.5 (md5) 


05 00 








NULL 


30 OD 








SEQUENCE (len = 13) 


06 09 








OBJECT IDENTIFIER = 1.2.840.113594.1.1.1 (rsa) 


05 00 








NULL 


04 82 


00 


80 




OCTET STRING (len = 128) 
signature 
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Annex E (informative): 
Example messages 



This annex provides complete example messages for several information exchanges. The messages included are full and 
complete, but subject to the following modifications for readability: 

• the content-type field of the HTTP header is shown as several lines. In actual implementations, that field will 
be constrained to a single line in conformance with HTTP specifications; 

• extra whitespace is included within the example XML documents. In actual implementations, this whitespace 
shall be removed before the digital signature is generated (according to the constraints of clause 7), and is not 
likely to be included in the actual transferred data; 



• 



the digital signatures within the example messages do not represent the actual digital signature for the example 
content. Actual signatures would likely result in unprintable characters. 



E.1 Pricing exchange 



The following two messages convey pricing information between two parties. The first message provides three separate 
price indications. Taken together, the three indications represent prices for basic Internet telephony service (thus the 
empty <Service> element) of '/i DM/minute to Berlin (country code 49, national destination code 30) 1 DM/minute 
elsewhere in Germany (country code 49), and 2 DM/minute elsewhere in the world. In all three cases no constraints are 
placed on the calling party (thus the empty <SourceInf o> elements). 

POST scripts/settlements HTTP/1.0 
content-type: multipart/signed; 

protocol="application/pkcs7-signature"; 

micalg=shal; 

boundary=bar 
content-length: 1968 

— bar 

Content-Type: text/plain 

Content-Length: 1647 

<?xml version= ' 1 . ' ?> 

<Message messageld="a" random="1234"> 
<PricingIndication component Id="b"> 
<Timestamp> 

1998-04-20T19:03:00Z 
</Timestamp> 

< Source Info type="el64pref ix" /> 
<DestinationInfo type="el64pref ix" /> 
<Currency> 

DEM 
</Currency> 
<Amount> 

2 
</Amount> 
<Increment> 

60 
</Increment> 
<Unit> 

s 
</Unit> 
<Service/> 
<ValidAfter/> 
<ValidUntil/> 
</PricingIndication> 
<PricingIndication component I d="c"> 
<Timestamp> 

1998-04-20T19:03:02Z 
</Timestamp> 

<SourceInfo type="el64pref ix" /> 
<DestinationInfo type="el64pref ix"> 

49 
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</DestinationInfo> 
<Currency> 

DEM 
</Currency> 
<Amount> 

1 
</Amount> 
<Increment> 

60 
</Increment> 
<Unit> 

s 
</Unit> 
<Service/> 
<ValidAfter/> 
<ValidUntil/> 
</PricingIndication> 
<PricingIndication component Id="d"> 
<Timestamp> 

1998-04-20T19:03:05Z 
</Timestamp> 

< Source Info type="el64pref ix" /> 
<DestinationInfo type="el64pref ix"> 

4930 
</DestinationInfo> 
<Currency> 

DEM 
</Currency> 
<Amount> 

0.5 
</Amount> 
<Increment> 

60 
</Increment> 
<Unit> 

s 
</Unit> 
<Service/> 
<ValidAfter/> 
<ValidUntil/> 
</PricingIndication> 
</Message> 

— bar 

Content-Type ; application/pkcsV-signature 

Content-Length: 191 

GhyHhHUujhJhjH77n8HHGTrfvbnj75 6tbB9HG4VQpfyF4 67GhIGfHfYT64VQpfyF4 67GhIGfHfYT6jH77n8HH 
GghyHhHUujhh756tbB9HGTrfvbnjn8HHGTrfvhJhjH77 6tbB9HG4VQbnj75 67GhIGfHfYT6ghyHhHUujpfyF4 
7GhIGfHfYT64VQbnj756 

— bar — 

The following example shows a confirmation in reply to the above message. In the confirmation, all pricing information 
is accepted. 

HTTP/ 1.0 200 OK 

content-type: multipart/signed; 

protocol="application/pkcs7-signature" ; 

micalg=shal; 

boundary=bar 
content-length: 1401 

— bar 

Content-Type: text/plain 

Content-Length: 1080 

<?xml version= ' 1 . ' ?> 

<Message messageld="a" random="1234"> 

<PricingConf irmation component Id="b"> 
<Timestamp> 

1998-04-20T19:04:00Z 
</Timestamp> 
<Status> 
<Code> 

201 
</Code> 
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<Description> 

new pricing created 
</Description> 
</Status> 
</PricingConf irmation> 
<PricingConf irmation component I cl="c"> 
<Timestamp> 

1998-04-20T19:04:22Z 
</Timestamp> 
<Status> 
<Code> 

210 
</Code> 
<Description> 

revised pricing accepted 
</Description> 
</Status> 
</PricingConf irmation> 
<PricingConf irmation component Id="d"> 
<Timestamp> 

1998-04-20T19:04:45Z 
</Timestamp> 
<Status> 

<Code> 

210 
</Code> 
<Description> 

revised pricing accepted 
</Description> 
</Status> 
</PricingConf irmation> 
</Message> 

— bar 

Content-Type : application/pkcs7-signature 

Content-Length: 191 

GhyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF4 67GhIGfHfYT64VQpfyF4 67GhIGfHfYT6j 
H77n8HHGghyHhHUujhJh756tbB9HGTrfvbnjn8HHGTrfvhJhjH77 6tbB9HG4VQbnj75 67GhIGfHfYT 
6ghyHhHUujpfyF47GhIGfHfYT64VQbnj756 

— bar— 



E.2 Authorization exchange 



The authorization exchange shows one party requesting and receiving authorization to access another party's devices. In 
particular, the requestor wishes to complete a phone call in which the calling party is at +81 45 881 1202 and the called 
party is at +47 66 84 13 60. 

POST scripts/settlements HTTP/1.0 
content-type: text/plain 
Content-Length: 600 

<?xml version= ' 1 . ' ?> 

<Message messageld="a" random="1234"> 

<AuthorizationRequest component Id="b"> 
<Timestamp> 

1998-04-24T17:03:00Z 
</Timestamp> 
<CallId encoding="base64 "> 

YT64VQpfyF4 67GhIGfHfYT6jH7 7n8HHGghyHhHUujhJh7 5 6t 
</CallId> 
<SourceInfo type="el64"> 

81458811202 
</SourceInfo> 
<DestinationInf o type="el64"> 

4766841360 
</Destinationlnfo> 
<Service/> 
<MaximumDestinations> 

5 
</MaximumDestinations> 
< /Author izationRe quest > 
</Message> 
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The reply to this request returns two separate authorizations, each representing a different peer system that is capable of 
completing the call. For each destination, the response authorizes up to 24 hours of service for the call. 

HTTP/1.0 200 OK 
content-type: text/plain 
Content-Length: 1799 

<?xml version= ' 1 . ' ?> 

<Message messagelcl="a" ranclom="1234"> 

<AuthorizationResponse component Icl="b"> 
<Timestamp> 

1998-04-24T17:03:01Z 
</Timestamp> 
<Status> 

<Code> 

200 
</Code> 
<Description> 

success 
</Description> 
</Status> 
<TransactionIcl> 

67890987 
</TransactionIcl> 
<Destination> 

<DestinationSignalAclclress> 

[172.16.1.2] :112 
</DestinationSignalAddress> 
<Token encoding="base64 "> 

YT64VQpfyF4 67GhIGfHfYT6jH7 7n8HHGghyHhHUujhJh7 56t 
HGTrfvbnjn8HHGTrfvhJhjH77 6tbB9HG4VQbnj75 67GhIGfH 
6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj 
</Tok:en> 
<ValidAfter> 

1998-04-24T17:01:01Z 
</ValidAfter> 
<ValidUntil> 

1998-04-24T17:ll:01Z 
</ValidUntil> 
<UsageDetail> 
<Service/> 
<Amount> 

24 
</Amount> 
<Increment> 

3600 
</Increment> 
<Unit> 

s 
</Unit> 
</UsageDetail> 
<CallId encoding="base64"> 

YT64VQpfyF4 67GhIGfHfYT6jH7 7n8HHGghyHhHUujhJh7 5 6t 
</CallId> 
</Destination> 
<Destination> 

<DestinationSignalAddress> 

[10.0.1.2] :112 
</DestinationSignalAddress> 
<Token encoding="base64 "> 

F4 67GhIGfHfYT6jH7 7n8HHGghyHliHUujliJli7 5 6tYT64VQpfy 
8HHGTrfvhJhjH77 6tbB9HG4VQbnj756HGTrfvbnjn7GliIGfH 
ujpfyF4 7GhIGfHfYT64VQbnj6ghyHhHU 
</To]<:en> 
<ValidAfter> 

1998-04-24T17:01:02Z 
</ValidAfter> 
<ValidUntil> 

1998-04-24T17:ll:02Z 
</ValidUntil> 
<UsageDetail> 
<Service/> 
<Amount> 

24 
< /Amount > 
<Increment> 

3600 
</Increment> 
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<Unit> 



</Unit> 
</UsageDetail> 
<CallId encoding="base64"> 

YT64VQpfyF4 67GhIGfHfYT6jH7 7n8HHGghyHhHUujhJh7 5 6t 
</CallId> 
</Destination> 
< /Author izationResponse> 
</Message> 



E.3 Usage exchange 



The final examples demonstrate the exchange of usage information. The first message reports a call duration of 
10 minutes. 

POST scripts/settlements HTTP/1.0 
content-type: text/plain 
Content-Length; 926 

<?xml version= ' 1 . ' ?> 

<Message messageld="a" random="1234"> 
<Usage Indication component Id="b"> 
<Timestamp> 

1998-04-24T22:03:00Z 
</Timestamp> 
<Role> 

source 
</Role> 
<TransactionId> 

67890987 
</TransactionId> 
<CallId encoding="base64"> 

YT64VQpfyF4 67GhIGfHfYT6jH7 7n8HHGghyHhHUujhJh7 5 6t 
</CallId> 
<SourceInfo type="el64"> 

81458811202 
</SourceInfo> 
<SourceAlternate type=" subscriber "> 

8912342718473772 
</SourceAlternate> 
<DestinationInf o type="el64"> 

4766841360 
</DestinationInfo> 
<DestinationAlternate type=" transport "> 

[10.0.1.2] :112 
</DestinationAlternate> 
<UsageDetail> 
<Service/> 
<Amount> 

10 
< /Amount > 
<Increment> 

60 
</Increment> 
<Unit> 

s 
</Unit> 
<StartTime critical="false"> 

1999-05-02T19:03:00Z 
</StartTime> 
<EndTime critical="false"> 

1999-05-02T19:13:00Z 
</EndTime> 

<TerminationCause critical=" false "> 
<TCCode> 
1016 
</TCCode> 
<Description> 

normal call clearing 
</Description> 
</TerminationCause> 
</UsageDetail> 
</UsageIndication> 
</Message> 



£75/ 



60 ETSI TS 101 321 V4.1.1 (2003-11) 



To complete the exchange, the server responds with a UsageConfirmation. 

HTTP/ 1.0 200 OK 
content-type: text/plain 
Content-Length: 404 

<?xml version= ' 1 . ' ?> 

<Message messagelcl="a" ranclom="1234"> 
<UsageConf irmation component Icl="b"> 
<Timestamp> 

1998-04-24T22:44:00Z 
</Timestamp> 
<Status> 

<Code> 

201 
</Code> 
<Description> 

new usage information created 
</Description> 
</Status> 
</UsageConf irmation> 
</Message> 



E.4 Subscriber authentication exchange 

The following two messages show the authentication of an individual subscriber. The first message requests 
authentication for ISO/IEC 7812-1 [29] (calling card or charge card) number 5100123456789012. 

POST scripts/settlements HTTP/1.0 
content-type: text/plain 
Content-Length: 336 

<?xml version= ' 1 . ' ?> 

<Message messageld="a" random="1234"> 

<SubscriberAuthenticationRequest component I d="b"> 
<Timestamp> 

1998-04-24T17:03:00Z 
</Timestamp> 
<SourceInfo type="iso7812"> 

5100123456789012 
</SourceInfo> 
</SubscriberAuthenticationRequest> 
</Message> 

The following response indicates a successful authentication. 

HTTP/ 1.0 200 OK 
content-type: text/plain 
Content-Length: 427 

<?xml version= ' 1 . ' ?> 

<Message messageld="a" random="1234"> 

< Subs criberAuthenti cat ionResponse component I d="b"> 
<Timestamp> 

1998-04-24T17:03:01Z 
</Timestamp> 
<Status> 

<Code> 

200 
</Code> 
<Description> 

success 
</Description> 
</Status> 
</ Subs criberAuthenti cat ionResponse> 
</Message> 



£75/ 



61 ETSI TS 1 01 321 V4.1 .1 (2003-1 1 ) 



E.5 Capabilities exchange 



This clause illustrates the exchange of capabilities between client and server. In the first message, the client identifies its 
manufacturer's serial number, indicates that it can support OSP V2.1.1, that it expects to send AuthorizationRequest and 
Usagelndication messages, and that it has a total of 64 kbit/s of capacity available. 

POST scripts/settlements HTTP/1.0 
content-type: text/plain 
Content-Length: 779 

<?xml version= ' 1 . ' ?> 

<Message messagelcl="a" ranclom="1234"> 

<CapabilitiesInclication componentIcl="b" critical="false"> 
<DeviceInfo type="serialnumber" critical="false"> 

12345678 
</DeviceInfo> 
<OSPVersion critical="f alse"> 

2.1.1 
</OSPVersion> 
<OSPCapability critical=" false "> 

AuthorizationRequest 
</OSPCapability> 
<OSPCapability critical=" false "> 

Usagelndication 
</OSPCapability> 
<Resources critical="false"> 

<DataRate critical="false"> 

<Bandwidth critical="false"> 

64000 
</Bandwidth> 
</DataRate> 
</Resources> 
</CapabilitiesIndication> 
</Message> 

The server replies with a confirmation that it can support OSP V2.1.1, and it provides URLs for the client to use for 
OSP services. 

HTTP/1.0 200 OK 

Expires: Thu, 01 Dec 2000 16:00:00 GMT 
content-type: text/plain 
Content-Length: 1542 

<?xml version= ' 1 . ' ?> 

<Message messageld="a" random="1234"> 

<CapabilitiesConf irmation componentId="b" critical="false"> 
<Timestamp> 

1998-04-24T22:44:00Z 
</Timestamp> 
<Status> 
<Code> 

200 
</Code> 
</Status> 
<OSPVersion critical="false"> 

2.1.1 
</OSPVersion> 
<OSPService critical="f alse"> 

<OSP Capability critical=" false "> 

AuthorizationRequest 
</OSPCapability> 
<OSPServiceURL critical=" false "> 

http : // server 1 . domain . com/osp/authreq 
</OSPServiceURL> 
<OSPServiceURL critical=" false "> 

http : //server 2 . domain . com/osp/authreq 
</OSPServiceURL> 
<OSPSignatureRequired critical=" false "> 

false 
</OSPSignatureRequired> 
</OSPService> 
<OSPService critical="false"> 

<OSPCapability critical=" false "> 
Usagelndication 
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</OSPCapability> 

<OSPServiceURL critical=" false "> 

http ; // server 1 . domain . com/osp/usageind 
</OSPServiceURL> 
<OSPServiceURL critical=" false "> 

http: //server 2 . domain. com/osp/usageind 
</OSPServiceURL> 
<OSPSignatureRequired critical=" false "> 

false 
</OSPSignatureRequired> 
</OSPService> 
</CapabilitiesConf irmation> 
</Message> 



£75/ 



63 



ETSI TS 101 321 V4.1.1 (2003-11) 



Annex F (informative): 
Billing format conversion 



A wide variety of billing formats are currently in use within telecommunications and data networking systems. One of 
the advantages of using extensible Markup Language within the present document is that it allows extremely easy 
conversion of usage information to and from other formats. As a demonstration of that flexibility, this annex includes 
example software to covert from <UsageIndication> components to a proprietary call detail record format of one 
particular, commercially-available system - the VocalTec Internet Telephony Gateway version 3.1. The software is 
written in Java, and relies on an XML parser available from Microsoft at http://www.microsoft.com/xml. Both the 
gateway and XML parser are selected solely to demonstrate the ease of the format conversion; this annex does not 
imply the suitability or fitness of either product for any purpose. 



import 


com, 


. ms 


. xml , 


. parser . *; 


import 


com, 


. ms 


. xml , 


. om. Document; 


import 


com, 


. ms 


. xml , 


. om. Element; 


import 


com. 


. ms 


. xml , 


. ut i 1 . XMLOut put St ream; 


import 


com. 


. ms 


. xml , 


. util . Name; 


import 


com. 


. ms . 


. xml , 


. om. Element Enumeration; 



import com.ms . xml . om. Element Imp 1; 

import Java . util . Enumeration; 

import java.io.*; 

import Java . io . PrintStream; 

import java.net.*; 

import Java. util.*; 

import com.ms . xml . util . Name; 

import com.ms . xml . om. ElementFactory; 

class CDR 



public static void main (String args[]) 
{ 

// "fix" the version to 2 digits to workaround a bug in the XML parser 

Properties props = new Properties (); 

props = System. getProperties (); 

props. put (" Java. version", "1.1"); 

System. setProperties (props); 

parseArgs (args); 

if (fileName == null) 

printUsage (System. out ) ; 
else 
{ 

URL url = createURL (fileName) ; 

Document d = null; 

try 

{ 

d = new Document (); 

d. setCaselnsensitive (true); 

d. setLoadExternal (true); 

d. load (url) ; 
} 
catch (ParseException e) 



{ 



) 



System. out .println (e); 



if (d != null) 
{ 

loadValues (d) ; 

// type 

cdr = pad ("Voice", 10); 

// date 

cdr += pad ( ( (timestamp == null) ? " — " : 

timestamp. substring (5, 10) + "-" + timestamp . substring (2, 4)), 10); 
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// time 

cdr += pad ( ( (timestamp == null) ? " — " : 
timestamp . substring (11, 19)), 10); 

// duration 

cdr += pad (((unit != null && unit. equals ("s") && amount != null && 

increment != null) ? "" + Integer .parseint (amount) * 

Integer .parseint (increment) : " — "), 10); 

// username 

cdr += pad ("User Name", 30); 

// dialed number 

cdr += pad (destinationinfo, 30); 

// line 

cdr += pad ("1", 10) ; 

// remote name 

cdr += pad ("Remote Name", 30); 

// disconnect reason 

cdr += pad ("Disconnect Reason", 40); 

// remote IP 

cdr += pad ("000.000.000.000", 20); 

// remote code 

cdr += pad ("0000", 15); 

// call type 

cdr += pad ((role != null && role. equals ("destination") ? "IPVOD" : "OPVOD"), 15); 

// user ID 

cdr += pad ("000000", 10); 

// fax pages 

cdr += pad ("", 13) ; 

// remote fax ID 
cdr += pad ("", 25); 

// local fax ref 
cdr += pad ("", 16) ; 

// remote fax ref 
cdr += pad ("", 16) ; 

// fax transfer mode 
cdr += pad ("", 18) ; 

// E.164 number 

cdr += pad (destinationinfo, 24); 

System. out . println (cdr); 
} 
} 

System. exit (0) ; 
} 

static void printUsage (PrintStream o) 
{ 

o. println ("Usage: Java CDR filename"); 

o . println ( ) ; 
} 

static void parseArgs (String args [ ] ) 
{ 

if (args . length> 0) 

fileName = args [0]; 
) 

static String pad (String s, int num) 
{ 

String str; 

int len; 

if (s == null) 
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str 
len 



4; 



else 



str = s; 

len = s . length ( ) , 

if (len> num) 

{ 



str 
len 



4; 



for (int 1 = len; i <num; i++) 

str += " "; 
return str; 



static URL createURL (String fileName) 

// Microsoft method 

{ 

URL url = null; 

try 

{ 

url = new URL (fileName) ; 
} 

catch (Malf ormedURLException ex) 
{ 

File f = new File (fileName); 

try 

{ 

String path = f . getAbsolutePath ( ) ; 

String fs = System. getProperty ( "file . separator ") ; 

if (fs.lengthO == 1) 

{ 

char Sep = f s . charAt (0); 
if (sep != '/') 

path = path. replace (sep, '/'); 
if (path. CharAt (0) != '/') 
path = ' / ' + path; 
} 

path = "file://" + path; 
url = new URL (path) ; 
} 

catch (Malf ormedURLException e) 
{ 

System. out . println ("Cannot create url for: " + fileName), 
System. exit (0) ; 



return url; 



static void loadValues (Element e) 



String attName 
String tagName; 



-NULL- 



if (e.getTagName () != null) 
{ 

attName = e.getText (); 

tagName = e.getTagName O.toString (); 

if (tagName. equals ( "TIMESTAMP" ) ) 
timestamp = attName; 

if (tagName. equals ( "DESTINATIONINFO" ) ) 
destinationinf o = attName; 

if (tagName. equals ("AMOUNT")) 
amount = attName; 

if (tagName. equals ("INCREMENT")) 
increment = attName; 

if (tagName. equals ("UNIT")) 
unit = attName; 
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if (tagName . equals ("ROLE")) 
role = attName; 



for (ElementEnumeration en = new ElementEnumeration (e) ; en.hasMoreElements ( ) ; ) 



Element child = (Element) en. nextElement ( ) , 
loadValues (child) ; 



static String fileName, timestamp, destinationinfo, amount, increment, unit, role, cdr; 
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Annex G (informative): 
XIVIL overview 



As an aid to those readers unfamiliar with Extensible Markup Language, this annex offers a brief overview of the 
syntax of XML documents. Key components of XML structure are document definitions, element declarations, and 
attribute declarations. 

NOTE: This annex is neither authoritative nor complete. A formal definition of XML may be found in [2]. 



G.1 Document definition 

XML documents are defined using the following format: 

<!DOCTYPE DocumentName [DocumentStructureDef inition] > 

DocumentName is the name of the XML document, and DocumentStructureDef nition is a series of element, 
attribute, and entity declarations. Those declarations are described below. An example document definition is: 



<!DOCTYPE Z [ 

<! ELEMENT Y (X, W) > 

<!ATTLIST Y ( 'a' I 'b' 

<! ELEMENT X CDATA> 

<! ELEMENT W CDATA> 

]> 



'a' #REQUIRED> 



G.2 Element declaration 

XML elements are declared using the following format: 

<! ELEMENT ElementName (ElementContents ) > 

ElementName, as expected, is the name of the element being declared, while ElementContents specifies the 
permissible contents of the element. Elements may include child elements, in which case the ElementContents part 
defines their order and number within the parent element, and element may include character data. 

Child elements within the ElementContent s part of a declaration may be designated as a sequence of child 
elements or a choice of child elements. The comma (,) separates individual child elements in a sequence, while the 
vertical bar (I) separates child elements in a choice. For example, < ! ELEMENT Y (X, W) > indicates that element Y 
consists of a child element X followed by a child element W. Similarly, < ! ELEMENT Z (X | W) > indicates that 
element Z consists of either a child element X or a child element W. 

The element declaration indicates the number of child elements permitted by a character following the child element's 
name. No character indicates that exactly one child element, a question mark (?) indicates zero or one child element, an 
asterisk (*) indicates zero or more child elements, and a plus (+) indicates one or more child elements. 

For example: 

<!ELEMENT X (A, B?, C*, D+)> 

defines element X as consisting of: 

Table G.I 



Child 
element 


Element 
declaration 


meaning 


A 


(none) 


exactly one child element 


B 


? 


zero or one child element 


C 


* 


zero or more child elements 


D 


+ 


one or more child elements 
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G.3 Attribute declaration 

XML attributes are associated with elements; they are declared using the format: 

<!ATTLIST ElementName AttributeNamel DeclaredValuel Def aultValuel 
AttributeName2 DeclaredValue2 DefaultValue2 

AttributeNameN DeclaredValueN Def aultValueN> 

ElementName identifies the XML element with which the attributes may be used. AttributeNamel, 
AttributeName2, ... are the names of the attributes defined for the element. Each attribute has either a list of 
permissible values or a data type, which the above construction labels DeclaredValue. The final part of each 
attribute's declaration is Def aultValue, which indicates the default value for the attribute, as well as constraints on 
its presence. 

Explicit, permissible values for attributes are separated by the vertical bar (I). So that, for example the Boolean 
attribute for element X may be declared as: 

<!ATTLIST X Boolean (true 1 false) > 

NOTE 1 : No default value is specified in the above declaration. If a default value is specified, then the 
Default Value clause may appear as one of: 

#REQUIRED: some explicit value for the attribute shall be included each time the attribute is used; 

# IMPLIED: if no explicit value for the attribute is used, then the application may infer a default value; 

"value "if no explicit value for the attribute is used, then the attribute should be assumed to have the 
value "value"; 

#FIXED "value" : the attribute shall have, and can only have, the value "value". 

EXAMPLE: If the Boolean attribute should be assumed to be true unless otherwise, explicitly indicated, the 
following declaration would apply. 

<!ATTLIST X Boolean (true I false) 'true'> 

NOTE 2: No quotation marks are used in the DeclaredValue part, while the Def aultValue part does 
enclose the value in quotations. 
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Annex H (informative): 

Binary XIVIL content format for OSP 



In some implementations, minimizing the size of protocol messages is a critical requirement. The Binary XML Content 
Format [28], developed by the Wireless Application Protocol (WAP) Forum provides a standard method for 
compressing XML content, and it can be directly applied to OSP messages. This annex provides the information 
necessary to use Binary XML Content Format in an interoperable manner by defining global extension tokens for OSP. 
It also includes an example message to illustrate the application of the format. 



H.1 Global extension tokens 

The following tables define the global extension tokens for OSP. 

Table H.I : Global extension tokens for OSP tags 



Code page 


Token 


Tag name 





05 


AlmostOutOfResources 





06 


Amount 





07 


AuthorityURL 





08 


AuthorizationConfirmation 





09 


Authorizationlndication 





OA 


AuthorizationRequest 





OB 


AuthorizationResponse 





OC 


Bandwidth 





OD 


Callld 





OE 


Certificate 





OF 


CertificateChain 





10 


Code 





11 


Currency 





12 


Data Rate 





13 


Description 





14 


Destination 





15 


DestinationAlternate 





16 


Destinationlnfo 





17 


DestinationSignalAddress 





18 


Deviceld 





19 


Devicelnfo 





1A 


Endlime 





IB 


Fraction 





1C 


Increment 





ID 


Loss Received 





IE 


LossSent 





IF 


MaximumDesti nations 





20 


Mean 





21 


Message 





22 


Minimum 





23 


NumberOfChannels 





24 


OneWayDelay 





25 


Pacl<ets 





26 


ReauthorizationRequest 





27 


ReauttiorizationResponse 





28 


Resources 





29 


Role 





2A 


RoundlripDelay 
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Code page 


Token 


Tag name 





2B 


Samples 





2C 


Service 





2D 


SourceAlternate 





2E 


Sourcelnfo 





2F 


SourceSignalAddress 





30 


Startlime 





31 


Statistics 





32 


Status 





33 


TCCode 





34 


TerminationCause 





35 


Timestamp 





36 


Token 





37 


Tokenlnfo 





38 


Transactionid 





39 


Unit 





3A 


UsageConfirmation 





3B 


UsageDetail 





3C 


Usagelndication 





3D 


ValidAfter 





3E 


ValidUntil 





3F 


Variance 




05 


CapabilitiesConfirmation 




06 


Capabilitieslndication 




07 


OSPCapability 




08 


OSPService 




09 


OSPServiceURL 




OA 


OSPSignatureRequired 




OB 


OSPVersion 




OC 


PricingConfirmation 




OD 


Pricinglndication 




OE 


SubscriberAuthenticationlnfo 




OF 


SubscriberAuthenticationRequest 




10 


SubscriberAuthenticationResponse 



£75/ 



71 ETSI TS 101 321 V4.1.1 (2003-11) 



Table H.2: Global extension tokens for OSP attributes 

Token Attribute 

05 componentid 

06 critical false 

07 critical true 

08 encoding base64 

09 encoding cdata 
OA messageld 

OB random 

OC type abbreviated 

OD type customerld 

OE type deviceld 

OF typed 64 

10 type e164prefix 

1 1 type email 

12 type epin 

1 3 type h323 

14 type international 

15 typeiso7812 

1 6 type national 

1 7 type network 

18 type pin 

19 type serialnumber 
1A type subscriber 

1 B type transport 

1 C type uri 



H.2 Example application 



This clause illustrates the process of converting an OSP message to Binary XML Content Format. It uses the example 
AuthorizationRequest from annex E. 

H.2.1 Standard XML format (505 bytes) 

<?xinl version=' 1 . ' ?> 

<Message messageld="a" random="1234 "> 

<AuthorizationRequest component Id="b"> 
<Timestamp> 

1998-04-24T17:03:00Z 
</Timestamp> 
<CallId encoding="base64"> 

YT64VQpfyF4 67GhIGfHfYT6 jH7 7n8HHGghyHhHUujhJh7 5 6t 
</CallId> 
<SourceInfo type="el64"> 

81458811202 
</SourceInfo> 
<DestinationInf o type="el64"> 

4766841360 
</DestinationInfo> 
<Service/> 
<MaximumDestinations> 

5 
</MaximumDestinations> 
</ Author izationRequest> 
</Message> 
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H.2.2 Binary XML content format (1 60 bytes) 

02 01 03 00 

El OA 03 'a' 00 OB 03 '1234' 00 
CA 05 03 'b' 00 

75 03 '1998-04-24T17:03:00Z' 00 01 
CD 08 01 03 

' YT64VQpfyF467GhIGfHfYT6 jH77n8HHGghyHhHUujhJh756t ' 00 01 
EE OF 01 03 '81458811202'00 01 
D6 OF 01 03 '4766841360'00 01 
2C 

5F 03 '5'00 01 
01 
01 
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Annex I (informative): 

PICS proforma for OSP (Reference) 

At the time of writing, the available Protocol Implementaion Conformance Statement (PICS) for OSP is contained in 
TS 101 336 VI. 1.1 [34], published in January 2000, which appHes to TS 101 321 Vl.4.2 (OSP). Now a new version of 
the PICS, as well as Test Suite Structure and Test Purposes (TSS & TPS) and Abstract Test Suite (ATS) will be 
pubHshed by ETSI early 2004 as TS 101 336-1, TS 101 336-2 and TS 101 336-3 (see bibHography). 
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Annex J (informative): 

OSP applications and implementations 

This annex describes the application of the Open Settlement Protocol, in various network implementations. Further call 
scenarios are described in TS 101 336 [34]. 



J.1 Call control protocols 



The Open Settlement Protocol (OSP) is not limited to any particular call control protocol. Rather, it is neutral, and is 
designed for deployment with devices conforming to H.323 [12] and Session Initiation Protocol (SIP), as well as 
various proprietary signalling protocols. 

NOTE: Some well-known IP telephony protocols, including the Simple Gateway Control Protocol (SGCP), IP 
Device Control (IPDC), Media Gateway Control Protocol (MGCP), and MEGACO/H.248, do not 
integrate directly with OSP. Instead, systems relying on those protocols integrate with OSP at the level of 
protocols between gateway controllers (e.g. call agents). Today, those protocols are primarily based on 
H.323 [12] or SIP. 

This clause illustrates how OSP may be used with various call signalling protocols. Rather than considering each 
protocol separately, however, it considers three different architectures peer-to-peer, distributed tightly-coupled, and 
distributed loosely-coupled that can be applied to various signalling protocols. The H.323 [12] and SIP protocols are 
used as examples to describe the interaction with OSP in detail. The principals described in these clauses can also be 
used for other protocols. 

J.1 .1 Peer-to-Peer architecture 

In a peer-to-peer architecture, gateways contact each other directly, without any control or co-ordination from other 
devices. This architecture corresponds to simple H.323 [12] deployments without gatekeepers as well as basic 
SIP-based services. In such an environment, the endpoints of a call implement the open settlement protocol to find and 
authorize each other, and to directly report usage information to a settlement provider. Clauses J. 1.1.1 and J. 1.1. 2 
illustrate the use of OSP and in both H.323 [12] and SIP architectures. 

J. 1.1.1 H.323 Gateways 

When operating with H.323 [12] gateways, OSP provides services at both the start and end of each call. During initial 
call setup, gateways can use OSP to obtain call routing information and authorization tokens. Once the call has ended, 
gateways use OSP to report usage details. 
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J.1 .1 .1 .1 Call routing and authorization 

Figure J.l shows how the open settlement protocol may be used by H.323 [12] gateways to find and authorize each 
other. 



Telephone 




Telephone 



o 



dial 
number 



Setup / 
Release Complete 



<AuthReq> 



H.323 Gateway B 

©ring |^ 
phone %^^ 
Setup / 
Setup Ack 



H.323 Gateway C 




Figure J.l 

Figure J.l highlights the following interactions between the devices. 

Calling party indicates the desired, destination phone number to Gateway A (by, for example, responding to a 
DTMF-based IVR, sending an ISDN Q.931 Setup, or transmitting an SS7 Initial Address Message). 

Gateway A sends an OSP <AuthorizationRequest> message to the OSP Server. The significant elements within 
the <AuthorizationRequest> include: 



<Timestamp> 

<CallId> 

<SourceInfo type="el64"> 



< Sour ceAlte mate 

type="transpor 
t"> 

<DestinationInf o type="el64"> 

<Service/> 

<MaximumDestinations> 



Time of request 

H.323 [1 2] Call Identifier to be used for the call 

Calling party's E.164 [11] number if available; otherwise a local 

E.164 [11] number controlled by Gateway A, e.g. 14048724887; this 

number shall be passed to the destination gateway(s) in Setup 

messages 

DNS name or IP address of Gateway A, for example 

gatewayA. carrier . com 

Called party's E.164 [11] number, e.g. 33492944299 

Empty (for basic service) 

The maximum number of destinations, including alternatives, Gateway 
A will consider 
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OSP Server replies with an <AuthorizationResponse> message. The message indicates two candidate 
destinations: Gateway B and Gateway C, in that order. In particular, the <AuthorizationResponse> contains the 
following elements: 



<Timestamp> 
<Status> 
<TransactionIcl> 
<Destination> 



Time of response 

Result of response, e.g. <Code>200</Code> 

Transaction identifier assigned by settlement provider 

First destination gateway to try for call 

DNS name or IP address of Gateway B, for example 

<DestinationS gateways . itsp . fr 
ignal Address 

type="transpo 



rt"> 
<Token> 
<ValidAfter> 
<ValidUntil> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
<CallId> 
<Destination> 



<DestinationS 
ignal Address 

type="transpo 
rt"> 



<Token> 
<ValidAfter> 
<ValidUntil> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
<CallId> 



Authorization token to be passed to Gateway B 

Time after which token for Gateway B Is valid 

Time until which token for Gateway B is valid 

How much service is authorized with Gateway B 

Empty (for basic service) 

Amount of authorized service, e.g. 3 600 

Increment of service measurement, e.g. i 

Unit of service measurement, e.g. s for seconds 

H.323 [12] Gall Identifier to be used for the call to Gateway B 

Second destination gateway to try for call 

DNS name or IP address of Gateway 0, for example 

gatewayC .isp.fr 



Authorization token to be passed to Gateway 

Time after which token for Gateway is valid 

Time until which token for Gateway is valid 

How much service is authorized with Gateway 

Empty (for basic service) 

Amount of authorized service, e.g. 3 600 

Increment of service measurement, e.g. i 

Unit of service measurement, e.g. s for seconds 

H.323 [12] Gall Identifier to be used for the call to Gateway C 



Gateway A sends an H.225.0 [8] Setup message to Gateway B; however, the Setup is refused with a Release Complete. 

NOTE: The H.323 [12] Call Identifier in the Setup message has the same value as in the original 

<AuthorizationRequest>. The Setup shall also include the authorization token(s) provided in the 
OSP <AuthorizationResponse>. For maximum interoperability, any tokens should use the 
following object identifier, constructed according to ETSI guidelines: 

itu-t(O), identified-organization(4), etsi(O), ts-101-321(1321), token(l), xml-format(2) 

Gateway A then sends a second H.225.0 [8] Setup message, this time to Gateway C, and this time the Setup is accepted 
with a Setup Acknowledge. This Setup message also uses the H.323 [12] Call Identifier from the 
<AuthorizationRequest>, and the Setup message shall also include the authorization token(s) provided in the 
OSP <AuthorizationResponse>. For maximum interoperability, any tokens should use the following object 
identifier, constructed according to ETSI guidelines. 

itu-t(O), identified-organization(4), etsi(O), ts-101-321(1321), token(l), xml-format(2) 

Gateway C accepts the Setup and completes the call to the called party; the phone conversation can now take place. 
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J. 1.1. 1.2 Usage reports 

Once the call has ended, both gateways report usage details to an OSP server. As the following figure indicates, those 
reports are conveyed in OSP <UsageIndication> messages. 



Telephone 




^^ H.323 Gateway C 

<UsageCnf> ^^^ ^^ 
<Usagelnd> 



Figure J.2 

The steps shown in the figure are straightforward. 

Gateways A and C clear the call by exchanging an H.225.0 [8] Release Complete message. 

Gateway A sends a <UsageIndication> message to the OSP server. If Gateway A is not using any protocol 
extensions, the message will contain the following elements: 



<Timestamp> 

<Role> 

<TransactionId> 

<CallId> 

<SourceInfo type="el64"> 

< Sour ceAlte mate 

type="transpor 
t"> 

<DestinationInf o type="el64"> 

<DestinationAlternate 



time of request 

for Gateway A, source 

transaction ID assigned by OSP server in authorization response 

H.323 [12] Call Identifier used for the call 

calling party's E.I 64 [11] number as returned in the authorization 

response, e.g. 14048724887 

DNS name or IP address of Gateway A, for example 

gatewayA. carrier . com 

called party's E.164 [11] number, e.g. 33492944299 

DNS name or IP address of Gateway C, for example, 

gatewayC .isp.fr 



type="transpor 
t"> 

usage information for the call 

empty (for basic service) 

amount of service used, e.g. 300 

increment of service measurement, e.g. i 

unit of service measurement, e.g. s for seconds 

The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 



<UsageDetail> 
<Service/> 
<Ainount> 
<Increment> 
<Unit> 
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Gateway C also sends a <UsageIndication> to the OSP server. That message would include the following 
elements: 



<Timestamp> 

<Role> 

<TransactionIci> 

<CallId> 

<SourceInfo type="el64"> 

< Sour ceAlte mate 

type=" transport "> 

<DestinationInf o type="el64"> 

<DestinationAlternate 

type="transport "> 

<UsageDetail> 

<Service/> 

<Amount> 

<Increment> 

<Unit> 

<Statistics> 

<LossSent> 

<Packets> 

<Fraction> 
<LossReceivecl> 

<Packets> 

<Fraction> 
<OneWayDelay> 

<Minimum> 

<Mean> 

<Variance> 

<Samples> 
<RoundTripDelay> 

<Minimum> 

<Mean> 

<Variance> 

<Samples> 



time of request 

for Gateway C, destination 

transaction ID assigned by OSP server and passed to 
Gateway in authorization tol<en 
H.323 [12] Gall Identifier used for the call 

calling party's E.164 [11] number as presented in the Setup 

message, e.g. 14048724887 

DNS name or IP address of Gateway A, for example 

[172.16.1.1] 

called party's E.164 [11] number, e.g. 33492944299 

DNS name or IP address of Gateway 0, for example, 

gatewayC . isp . f r 

usage information for the call 

empty (for basic service) 

amount of service used, e.g. 300 

increment of service measurement, e.g. i 

unit of service measurement, e.g. s for seconds 

statistical information for call 

loss information for packets sent by Gateway 

number of packets lost from Gateway to Gateway A 

fraction (from to 255) of packets lost from to A 

loss information for packets sent by Gateway A 

number of packets lost from Gateway A to Gateway 

fraction (from to 255) of packets lost from A to 

one way delay measured from Gateway A to 

minimum measured value for delay, in seconds 

sample mean of delay measurements, in seconds 

sample variance of delay measurements, in squared seconds 

number of sample measurements 

round trip delay between Gateway A and measured during call 

minimum measured value for delay, in seconds 

sample mean of delay measurements, in seconds 

sample variance of delay measurements, in squared seconds 



number of sample measurements 

The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 



J.1 .1 .2 Session initiation protocol gateways 

In a simple peer-to-peer environment, Session Initiation Protocol (SIP) gateways operate in a manner nearly identical to 
H.323 [12] gateways. As before, it is convenient to consider interaction using OSP before and after the multimedia call. 
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J.1 .1 .2.1 Call routing and authorization 

Figure J. 3 shows how the open settlement protocol may be used by SIP gateways to find and authorize each other. 

NOTE 1 : This function allows a SIP gateway to find a peer gateway for a particular, PSTN-terminated, telephone 
user. As such, it is not the same as the standard SIP user location function. 



Telephone 




<AuthReq> 



SIP Gateway C 



OSP 
Server 



Figure J.3 

Figure J.3 highlights the following interactions between the devices. 

Calling party indicates the desired, destination phone number to Gateway A (by, for example, responding to a DTMF- 
based IVR, sending an ISDN Q.931 Setup, or transmitting an SS7 Initial Address Message). 

Gateway A sends an OSP <AuthorizationRequest> message to the OSP Server. The significant elements within 
the <AuthorizationRequest> include: 



<Timestamp> 

<CallId> 

<SourceInfo type="el64"> 



<SourceAlternate 

type="transpor 
t"> 

<DestinationInfo type="el64"> 

<Service/> 

<MaximumDestinations> 



time of request 

SIP [36] Call-ID to be used for the call 

calling party's E.164 [11] number if available; otherwise a local 

E.164 [11] number controlled by Gateway A, e.g. 14048724887; this 

number shall be passed to the destination gateway{s) in the 

subsequent INVITE method 

DNS name or IP address of Gateway A, for example 

gatewayA. carrier . com 



called party's E.164 [11] number, e.g. 33492944299 

empty (for basic service) 

the maximum number of destinations, including alternatives. Gateway 
A will consider 
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OSP Server replies with an <AuthorizationResponse> message. The message indicates two candidate 
destinations: Gateway B and Gateway C, in that order. In particular, the <AuthorizationResponse> contains the 
following elements: 



<Timestamp> 
<Status> 
<TransactionIcl> 
<Destination> 



time of response 

result of response, e.g. <Code>200</Code> 

transaction identifier assigned by settlement provider 

first destination gateway to try for call 

DNS name or IP address of Gateway B, for example 

<DestinationS gateways . itsp . fr 
ignal Address 

type="transpo 



rt"> 
<Token> 
<ValidAfter> 
<ValidUntil> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
<CallId> 
<Destination> 



<DestinationS 
ignal Address 

type="transpo 



authorization token to be passed to Gateway B 

time after which token for Gateway B is valid 

time until which token for Gateway B is valid 

how much service is authorized with Gateway B 

empty (for basic service) 

amount of authorized service, e.g. 3 600 

increment of service measurement, e.g. i 

unit of service measurement, e.g. s for seconds 

SIP [36] Call-ID to be used for the call to Gateway B 

second destination gateway to try for call 

DNS name or IP address of Gateway 0, for example 

gatewayC .isp.fr 



rt"> 
<Token> 
<ValidAfter> 
<ValidUntil> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
<CallId> 



authorization token to be passed to Gateway 

time after which token for Gateway is valid 

time until which token for Gateway is valid 

how much service is authorized with Gateway 

empty (for basic service) 

amount of authorized service, e.g. 3 600 

increment of service measurement, e.g. i 

unit of service measurement, e.g. s for seconds 

SIP Call-ID to be used for the call to Gateway C 

Gateway A sends an INVITE message to Gateway B; however, Gateway B cannot accept the request. It responds with a 
"503 Service Unavailable", which Gateway A acknowledges with an ACK. 

NOTE 2: The SIP Call-ID in the INVITE message has the same value as in the original 

<AuthorizationRequest>. The INVITE shall also include authorization token(s) provided in the 
OSP <AuthorizationResponse>. Each token should be conveyed in the SIP header, as initially 
defined in annex K. 

Gateway A then sends a second INVITE message, this time to Gateway C, and this time the INVITE is accepted with 
"200 Success", to which Gateway A replies with an ACK. This INVITE message also uses the SIP Call-ID from the 
<AuthorizationRequest>, and the INVITE shall also include the authorization token(s) provided in the OSP 
<AuthorizationResponse>. Each token should be conveyed in the SIP header, as initially defined in annex K: 

Gateway C accepts the INVITE and completes the call to the called party; the phone conversation can now 
take place. 
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J.1 .1 .2.2 Usage reports 

Once the call has ended, both gateways report usage details to an OSP server. As the following figure indicates, those 
reports are conveyed in OSP <UsageIndication> messages. 



Telephone 




SIP Gateway C 

o 

<Usagelnd> 



Figure J.4 

The steps shown in figure J.4 are straightforward. 

Gateways A and C clear the call with a SIP BYE message. 

Gateway A sends a <UsageIndication> message to the OSP server. If Gateway A is not using any protocol 
extensions, the message will contain the following elements: 



<Timestamp> 

<Role> 

<TransactionId> 

<CallId> 

<SourceInfo type="el64"> 

< Sour ceAlte mate 



time of request 

for Gateway A, source 

transaction ID assigned by OSP server in autliorization response 

SIP [36] Call-ID used for the call 

calling party's E.164 [11] number as returned in tine autliorization 

response, e.g. 14048724887 

DNS name or IP address of Gateway A, for example 

gatewayA. carrier . com 



type="transpor 
t"> 

<DestinationInfo type="el64"> Called party's E.164 [11] number, e.g. 33492944299 

<DestinationAiternate DNS name or IP address of Gateway 0, for example, 

gatewayC .isp.fr 
type="transpor 
t"> 

usage information for the call 

empty (for basic service) 

amount of service used, e.g. 300 

increment of service measurement, e.g. i 

unit of service measurement, e.g. s for seconds 



<UsageDetail> 
<Service/> 
<Ainount> 
<Increment> 
<Unit> 



The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 

Gateway C also sends a <UsageIndication> to the OSP server. 
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<Timestamp> 

<Role> 

<TransactionIcl> 

<CallId> 

<SourceInfo type="el64"> 

< Sour ceAlte mate 

type="transport "> 

<DestinationInf o type="el64"> 

<DestinationAlternate 

type="transport "> 

<UsageDetail> 

<Service/> 

<Amount> 

<Increment> 

<Unit> 

<Statistics> 

<LossSent> 

<Packets> 

<Fraction> 
<LossReceivecl> 

<Packets> 

<Fraction> 
<OneWayDelay> 

<Minimum> 

<Mean> 

<Variance> 

<Samples> 
<RoundTripDelay> 

<Minimum> 

<Mean> 

<Variance> 

<Samples> 



time of request 

for Gateway C, destination 

transaction ID assigned by OSP server and passed to Gateway 
in authorization token 
SIP Gall-ID used for tine call 

calling party's E.164 [11] number as presented in the INVITE 

message, e.g. 14048724887 

DNS name or IP address of Gateway A, for example 

[172.16.1.1] 

called party's E.164 [11] number, e.g. 33492944299 

DNS name or IP address of Gateway 0, for example, 

gatewayC . isp . f r 

usage information for the call 

empty (for basic service) 

amount of service used, e.g. 30 

increment of service measurement, e.g. i 

unit of service measurement, e.g. s for seconds 

statistical information for call 

loss information for packets sent by Gateway 

number of packets lost from Gateway to Gateway A 

fraction (from to 255) of packets lost from to A 

loss information for packets sent by Gateway A 

number of packets lost from Gateway A to Gateway 

fraction (from to 255) of packets lost from A to 

one way delay measured from Gateway A to 

minimum measured value for delay, in seconds 

sample mean of delay measurements, in seconds 

sample variance of delay measurements, in squared seconds 

number of sample measurements 

round trip delay between Gateway A and measured during call 

minimum measured value for delay, in seconds 

sample mean of delay measurements, in seconds 

sample variance of delay measurements, in squared seconds 



number of sample measurements 

The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 



J.1 .2 Tightly controlled distributed architecture 

The Open Settlement Protocol supports operation in a tightly controlled, distributed architecture. That architecture 
includes some H.323 [12]-based deployments with active gatekeepers and SIP proxy servers (but not SIP redirect 
servers). The following clauses illustrate the use of OSP in those environments. 
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J. 1.2.1 H.323 Gatekeeper routed calls 



In H.323 [12] deployments with gatekeepers, the gatekeeper may play a very active roll in call signalling. In such an 
environment, gatekeepers not only assume responsibility for call routing and authorization on behalf of their endpoints. 
They also act as the signalling endpoint for calls into their zone. As figure J. 5 shows, gatekeepers may support 
multimedia terminals as well as gateways. As that figure J. 5 and J. 6 also highlight, only gatekeepers are required to 
support the Open Settlement Protocol in this environment. 



H.323 Terminal 



Telephone 




111 I 



Setup/ ^ H.323 Gatekeeper A 
Setup Ack ^ ^-. 

o 

<AuttiRsp> 





Figure J.5 

NOTE: All destination gateways (or endpoints) controlled by the gatekeepers shall be equivalent, as far as the 
OSP server is concerned. Indeed, the OS? server is not even aware of the existence of any H.323 [12] 
terminals or gateways. Such an architecture, therefore, places implicit restrictions on the services offered 
by the operators. An operator, for example, will be unable to price termination services differently for 
different gateways in the same zone. 

J.I .2.1 .1 Call routing and authorization 

H.323 [12] Terminal begins a call by sending an H. 225.0 [8] Setup message its gatekeeper. Gatekeeper A. 

NOTE: This scenario assumes the use of pre-granted admission requests. 

The Setup indicates that the called party is identified by an E.164 [11] phone number such as +33 4 92 94 42 99. 

Gatekeeper A sends an OSP <AuthorizationRequest> message to the OSP Server. The significant elements 
within the <AuthorizationRequest> include: 



<Timestamp> 

<CallId> 

<SourceInfo type="el64"> 



<SourceAlternate 



time of request 

H.323 [1 2] Call Identifier to be used for the call 

a representation of the H.323 [12] Terminal using an E.164 [11] 
number; in the absence of other information, this number may be 
derived using the IP address to E.164 [11] number mapping of ETSI 
TIPHON; this number shall be passed to the destination gateway(s) 
in Setup messages 

DNS name or IP address of Gatekeeper A, for example 
gatekeeper A. carrier . com 



type="transpor 
t"> 



<DestinationInfo type="el64"> Called party's E.164 [11] number, e.g. 33492944299 

<service/> empty (for basic service) 

<MaximumDestinations> the maximum number of destinations, including alternatives, 

Gatekeeper A will consider 



ETSI 



84 



ETSI TS 101 321 V4.1.1 (2003-11) 



OSP Server replies with an <AuthorizationResponse> message. The message identifies Gatekeeper B. In 
particular, the <AuthorizationResponse> contains the following elements: 



<Timestamp> 
<Status> 
<TransactionId> 
<Destination> 



time of response 

result of response, e.g. <Code>200</Code> 

transaction identifier assigned by settlement provider 

first destination gateway to try for call 

DNS name or IP address of Gatekeeper B, for example 

<DestinationS gatekeeperB.itsp.fr 
ignalAddress 

type="transpo 



rt"> 
<Token> 
<ValidAfter> 
<ValidUntil> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
<CallId> 



authorization token to be passed to Gatekeeper B 

time after wfiich token for Gatekeeper B is valid 

time until wfiich token for Gatekeeper B is valid 

how much service is authorized with Gatekeeper B 

empty (for basic service) 

amount of authorized service, e.g. 3 600 

increment of service measurement, e.g. i 

unit of service measurement, e.g. s for seconds 

H.323 [12] Gall Identifier to be used for the call to Gatekeeper B 



Gatekeeper A extends the call with its own Setup message to Gatekeeper B. 

Gatekeeper B accepts the Setup and extends the call to the destination gateway with another Setup/Setup Acknowledge 
exchange. 

The Gateway adds the final leg of the call by dialling the called party; the phone conversation can now take place. 



J. 1.2.1.2 



Usage reports 



At the conclusion of the phone call, both gatekeepers shall report usage information to the OSP server. Figure J. 6 
identifies the principle steps of a typical call completion. 
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Figure J.6 
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The steps shown in figure J. 6 are straightforward. 

The gatekeepers release the call with an exchange of H. 225.0 [8] Release and Release Complete messages. 

Gatekeeper A then sends a <UsageIndication> message to the OSP server. In this example Gatekeeper A may not 
be able to support protocol extensions such as statistics. Its message, therefore contains just the following elements: 



<Timestamp> 

<Role> 

<TransactionId> 

<CallId> 

<SourceInfo type="el64"> 

< Sour ceAlte mate 

type="transpor 
t"> 

<DestinationInf o type="el64"> 

<DestinationAlternate 



time of request 

for Gatekeeper A, source 

transaction ID assigned by OSP server in authorization response 

H.323 [12] Call Identifier used for the call 

calling party's E.I 64 [11] number as returned in the authorization 

response, e.g. 14048724887 

DNS name or IP address of Gatekeeper A, for example 

gatekeeperA. carrier . com 

called party's E.164 [11] number, e.g. 33492944299 

DNS name or IP address of Gatekeeper B, for example, 

gatekeepers . itsp . f r 



type="transpor 
t"> 

usage information for the call 

empty (for basic service) 

amount of service used, e.g. 300 

increment of service measurement, e.g. i 

unit of service measurement, e.g. s for seconds 

The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 

Gatekeeper B also sends a <UsageIndication> to the OSP server. That message would include the following 
elements: 



<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 



<Timestamp> 

<Role> 

<TransactionId> 

<CallId> 

<SourceInfo type="el64"> 

< Sour ceAlte mate 

type="transport "> 

<DestinationInf o type="el64"> 

<DestinationAlternate 

type="transport "> 

<UsageDetail> 

<Service/> 

<Amount> 

<Increment> 

<Unit> 
<Statistics> 

<LossSent> 

<Packets> 

<Fraction> 

<LossReceived> 



time of request 

for Gatekeeper B, destination 

transaction ID assigned by OSP server and passed to 
Gatekeeper B in authorization token 
H.323 [12] Call Identifier used for the call 

calling party's E.164 [11] number as presented in the Setup 

message, e.g. 14048724887 

DNS name or IP address of H.323 [12] Terminal, for example 

[172.16.100.1] 

called party's E.164 [11] number, e.g. 33492944299 

DNS name or IP address of Gatekeeper B, for example, 

gatekeepers . itsp . f r 

usage information for the call 

empty (for basic service) 

amount of service used, e.g. 300 

Increment of service measurement, e.g. i 

unit of service measurement, e.g. s for seconds 

statistical information for call 

loss information for packets sent by Gatekeeper B 

number of packets lost from Gatekeeper B to H.323 [12] 

Terminal 

fraction (from to 255) of packets lost from B to H.323 [12] 

Terminal 

loss information for packets sent by H.323 [12] Terminal 
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<packets> number of packets lost from H.323 [12] Terminal to 

Gatekeeper B 
fraction (from to 255) of packets lost from Terminal to B 

one way delay measured from Terminal to B 

minimum measured value for delay, in seconds 

sample mean of delay measurements, in seconds 

sample variance of delay measurements, in squared seconds 

number of sample measurements 

round trip delay between Terminal and B measured during call 

minimum measured value for delay, in seconds 

sample mean of delay measurements, in seconds 

sample variance of delay measurements, in squared seconds 

number of sample measurements 

The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 



<Fraction> 
<OneWayDelay> 

<Minimum> 

<Mean> 

<Variance> 

<Samples> 
<RoundTripDelay> 

<Minimum> 

<Mean> 

<Variance> 

<Samples> 



J.1 .2.2 Session initiation protocol proxy servers 

Session Initiation Protocol (SIP) proxy servers may function in a manner similar to H.323 [12] gatekeepers. In such an 
envkonment, the proxy servers may support the Open Settlement Protocol, while the systems on whose behalf they act 
need not. 

NOTE: All destination gateways (or endpoints) served by the SIP proxies shall be equivalent, as far as the OSP 
server is concerned. Indeed, the OSP server is not even aware of the existence of any endpoints or 
gateways. Such an architecture, therefore, places implicit restrictions on the services offered by the 
operators. An operator, for example, will be unable to price termination services differently for different 
gateways served by the same proxy. 

J.1 .2.2.1 Call routing and authorization 

Figure J.7 shows how OSP plays a role in environments that use SIP Proxy Servers. Figure J. 7, The SIP Proxy Server, 
acting on behalf of the SIP client, completes a call to a SIP Gateway, and ultimately to the PSTN. 
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Figure J.7 
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The SIP Client begins a call by sending an INVITE request to its proxy server. The INVITE indicates that the called 
party is identified by an E. 164 [11] phone number such as +33 4 92 94 42 99. 

The SIP Proxy Server sends an OSP <AuthorizationRequest> message to the OSP Server. The significant 
elements within the <AuthorizationRequest> include the following: 



<Timestamp> 

<CallId> 

Oourcelnfo type="el64"> 



< Sour ceAlte mate 



time of request 

SIP Call-ID to be used for the call 

a representation of the SIP client using an E.164 [11] number; in the 
absence of other information, this number may be derived using the 
IP address to E.164 [11] number mapping of ETSI TIPHON. 
DNS name or IP address of the Proxy Server, for example 

proxy . carrier . com 



type="transpor 
t"> 



called party's E.164 [11] number, e.g. 33492944299 
empty (for basic service) 

the maximum number of destinations, including alternatives, the 

Proxy Server will consider 
OSP Server replies with an <AuthorizationResponse> message. The message identifies the SIP gateway. In 
particular, the <AuthorizationResponse> contains the following elements: 



<DestinationInf o type="el64"> 

<Service/> 

<MaximumDestinations> 



<Timestamp> 
<Status> 
<TransactionId> 
<Destination> 

<DestinationSignalAclclress 

type=" transport 
"> 



time of response 

result of response, e.g. <Code>200</Code> 

transaction identifier assigned by settlement provider 

first destination gateway to try for call 

DNS name or IP address of destination gateway, 
e.g. gateway.itsp.fr 



authorization token to be passed to Gateway 
time after which token for Gateway is valid 
time until which token for Gateway is valid 
how much service is authorized with Gateway 
empty (for basic service) 
amount of authorized service, e.g. 3600 
increment of service measurement, e.g. i 
unit of service measurement, e.g. s for seconds 
SIP Gall-ID to be used for the call to the Gateway 

The Proxy Server, acting on behalf of its client, sends an SIP INVITE to the Gateway. In this example, the Gateway 
accepts the connection with an 200, and the proxy responds with an ACK. This INVITE message also uses the SIP 
Call-ID from the <AuthorizationRequest>, and the INVITE shall also include the authorization token(s) 
provided in the OSP <AuthorizationResponse>. Each token should be conveyed in the SIP header, as initially 
defined in: draft- John ston-sip-osp-token-01 . txt. 

The Proxy Server, on establishing the connection with the Gateway, completes the connection with its client as well 
with a SIP 200/ ACK exchange. 

The Gateway, meanwhile, completes the call to the destination phone number. 



<Token> 
<ValidAfter> 
<ValidUntil> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
<CallId> 



£75/ 



88 



ETSI TS 101 321 V4.1.1 (2003-11) 



J. 1.2.2.2 Usage reports 

At the conclusion of the phone call, both the Proxy Server and Gateway report usage information to the OSP server. 
Figure J. 8 identifies the principle steps of a typical call completion. 



SIP Client 



Telephone 




Figure J.8 

The steps shown in figure J.8 are straightforward. 

The Proxy Server and Gateway release the call by transferring a SIP BYE message. 

The Proxy Server then sends a <UsageIndication> message to the OSP server. In this example, the Proxy Server 
does not support new protocol extensions such as statistics. Its message, therefore contains just the following elements: 



<Timestamp> 

<Role> 

<TransactionId> 

<CallId> 

<SourceInfo type="el64"> 

< Sour ceAlte mate 

type="transpor 
t"> 

<DestinationInf o type="el64"> 

<DestinationAlternate 

type="transpor 
t"> 



time of request 

for Proxy Server, source 

transaction ID assigned by OSP server in authorization response 

SIP Call-ID used fertile call 

calling party's E.164 [11] number as returned in tine autliorization 

response, e.g. 14048724887 

DNS name or IP address of the Proxy Server, for example 

proxy . carrier . com 

called party's E.164 [11] number, e.g. 33492944299 

DNS name or IP address of the Gateway, for example, 

gateway . itsp . f r 



usage information for the call 

empty (for basic service) 

amount of service used, e.g. 300 

increment of service measurement, e.g. i 

unit of service measurement, e.g. s for seconds 

The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 



<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
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The Gateway also sends a <UsageIndication> to the OSP server. That message would include the following 
elements: 



<Timestamp> 

<Role> 

<TransactionIci> 

<CallId> 

<SourceInfo type="el64"> 

< Sour ceAlte mate 

type=" transport "> 

<DestinationInf o type="el64"> 

<DestinationAlternate 

type="transport "> 

<UsageDetail> 

<Service/> 

<Amount> 

<Increment> 

<Unit> 

<Statistics> 

<LossSent> 

<Packets> 

<Fraction> 

<LossReceivecl> 
<Packets> 
<Fraction> 

<OneWayDelay> 

<iyiinimum> 

<Mean> 

<Variance> 

<Samples> 
<RoundTripDelay> 

<Minimum> 
<Mean> 
<Variance> 
<Samples> 



time of request 

for the Gateway, destination 

transaction ID assigned by OSP server and passed to the 
gateway in authorization tol<en 
SIP Call-ID used for the call 

calling party's E.164 [11] number as presented In the INVITE 

message, e.g. 14048724887 

DNS name or IP address of the Proxy Server, for example 

[172.16.100.1] 

called party's E.164 [11] number, e.g. 33492944299 

DNS name or IP address of the Gateway, for example, 

gateway. itsp . f r 

usage information for the call 

empty (for basic service) 

amount of service used, e.g. 300 

Increment of service measurement, e.g. i 

unit of service measurement, e.g. s for seconds 

statistical information for call 

loss Information for packets sent by the Gateway 

number of packets lost from the Gateway to the Proxy Server 

fraction (from to 255) of packets lost from the Gateway to the 

Proxy Server 

loss information for packets sent by the Proxy Server 

number of packets lost from Proxy Server to the Gateway 

fraction (from to 255) of packets lost from Proxy Server to 

Gateway 

one way delay measured from Proxy Server to Gateway 

minimum measured value for delay, in seconds 

sample mean of delay measurements, in seconds 

sample variance of delay measurements, in squared seconds 

number of sample measurements 

round trip delay between Proxy Server and Gateway measured 

during call 

minimum measured value for delay, in seconds 

sample mean of delay measurements, in seconds 

sample variance of delay measurements, in squared seconds 

number of sample measurements 



The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 

J.1 .3 Loosely controlled distributed architecture 

The Open Settlement Protocol can also be used in environments based on loosely-coupled, distributed architectures. 
One such environment is an H.323 [12]-based architecture with direct call signalling. Another example is the use 
Session Initiation Protocol (SIP) redirect servers. This clause describes the use of OSP in each of these architectures. 
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J. 1.3.1 H.323 Direct routed calls (with Gatekeepers) 

When H.323 [12] gateways and gatekeepers both implement the Open Settlement Protocol, it is possible to use OSP in 
an architecture that relies on H.323 [12] Direct Call Signalling (as opposed to Gatekeeper Call Signalling). Such an 
approach is a hybrid of the peer-to-peer gateway architecture and the tightly controlled gatekeeper model discussed in 
the previous two clauses. In this approach, the gatekeepers acts as agents for call routing and authorization, but the 
gateways themselves are responsible for establishing and disconnecting calls directly with each other. In addition to 
gateways, H.323 [12] proxy devices may also be used to support this model on behalf of H.323 [12] terminals. 

J.I .3.1 .1 Call routing and authorization 

Figure J. 9 shows a sample routing and authorization scenario for this model. 

NOTE 1 : Figure J. 9 shows a finer level of detail than previous examples in order to clarify several subtle points. 
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Figure J.9 

Gateway A begins a call by sending an H. 225.0 [8] Admission ReQuest (ARQ) to its gatekeeper. Gatekeeper A. The 
ARQ indicates that the called party is identified by an E. 164 [11] phone number such as -1-33 4 92 94 42 99. 
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Gatekeeper A sends an OSP <AuthorizationRequest> message to the OSP Server. The significant elements 
within the <AuthorizationRequest> include: 



time of request 

H.323 [1 2] Call Identifier to be used for the call 

the called party's E.164 [11] number, or, if that is not available, a local 
E.I 64 [11] number belonging to Gateway A; this number shall be 
passed to the destination gateway(s) in Setup messages 
DNS name or IP address of Gatekeeper A, for example 

gatekeeperA. carrier . com 

H.323 [12] identifier of Gateway A, e.g. 12345678 
called party's E.164 [11] number, e.g. 33492944299 
empty (for basic service) 

the maximum number of destinations, including alternatives, 

Gatekeeper A will consider 
OSP Server replies with an <AuthorizationResponse> message. The message identifies Gateway B and 
Gateway C as candidate destinations. In particular, the <AuthorizationResponse> contains the following 
elements: 



<Timestamp> 

<CallId> 

<SourceInfo type="el64"> 

< Sour ceAlte mate 

type="transpor 
t"> 

<SourceAlternate type="h323"> 

<DestinationInf o type="el64"> 

<Service/> 

<MaximumDestinations> 



<Timestamp> 
<Status> 
<TransactionIcl> 
<Destination> 

<DestinationSignalAclclress 

type=" transport" 
> 

<Token> 

<ValidAfter> 

<ValidUntil> 

<UsageDetail> 

<Service/> 

<Amount> 

<Increment> 

<Unit> 
<CallId> 
<Destination> 

<DestinationSignalAddress 

type=" transport" 



time of response 

result of response, e.g. <Code>200</Code> 
transaction identifier assigned by settlement provider 
first destination gateway to try for call 

DNS name or IP address of Gateway B, for example 

gateways . itsp . f r 

authorization token to be passed to Gateway B 

time after which token for Gateway B is valid 

time until which token for Gateway B is valid 

how much service is authorized with Gateway B 

empty (for basic service) 

amount of authorized service, e.g. 3600 

increment of service measurement, e.g. i 

unit of service measurement, e.g. s for seconds 

H.323 [12] Gall Identifier to be used for the call to Gateway B 

second destination gateway to try for call 

DNS name or IP address of destination Gateway C, e.g. 

gatewayC . isp . f r 



authorization token to be passed to Gateway 

time after which token for Gateway C is valid 

time until which token for Gateway is valid 

how much service is authorized with Gateway C 

empty (for basic service) 

amount of authorized service, e.g. 3600 

increment of service measurement, e.g. i 

unit of service measurement, e.g. s for seconds 

H.323 [12] Gall Identifier to be used for the call to Gateway 

Gatekeeper A sends an H. 225.0 [8] Admission ConFirm (ACF) message to its gateway. That ACF identifies the 
destination as Gateway B and it shall include the authorization token for gateway B. 



<Token> 
<ValidAfter> 
<ValidUntil> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
<CallId> 
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Gateway A sends an H. 225.0 [8] Setup message to Gateway B. This Setup message uses the H.323 [12] Call Identifier 
from the <AuthorizationRequest>, and the message shall include the authorization token(s) provided in the OSP 

<AuthorizationResponse>. 

Gateway B refuses the setup attempt with a Release Complete message, perhaps, for example, because no outbound 
PSTN ports are available. 

Gateway A sends another Admission Request (ARQ) message to its gatekeeper to request an alternate destination for 
the phone call. 

NOTE 2: This ARQ shall use the same H.323 [12] Call Identifier as the original ARQ. For clarity, the example 
omits other details of the exchange between Gateway A and Gatekeeper A, such as, for example, a 
Disengage Request (DRQ) and Disengage Confirm (DCF). 

Gatekeeper A replies with an Admission Confirm (ACF) message that identifies Gateway C as a potential destination. 

NOTE 3: The Gatekeeper need not query the OSP server to get that information. Rather, the information is 
available in the original <AuthorizationResponse> noted in step 3. 

Gateway A tries a second setup attempt, this time by sending a Setup message to Gateway C. 

Gateway C receives the Setup message and asks its gatekeeper for permission to accept the call. It does so by sending 
an Admission Request (ARQ) to Gatekeeper C. 

NOTE 4: This message shall include the authorization token(s) received in the Setup. 

Gatekeeper C authorizes the call and returns an Admission Confirm (ACF) message to Gateway C. 

Gateway C receives the ACF and accepts the call by returning a Setup Acknowledge message to Gateway A. 

J.1 .3.1 .2 Usage reports 

At the conclusion of the phone call, both gateways shall report usage information to the OSP server. Figure J. 10 
identifies the principle steps of a typical call completion. 
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Figure J. 10 

The steps shown in the figure are straightforward. 

The gateways close the connection by exchanging H.323 [12] Release and Release Complete messages. 
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Gateway A then sends a <UsageIndication> message to the OSP server. In this example Gateway A's message 
will include two complete <UsageIndication> components, one for the failed attempt and one for the successful 
call. The sub-elements for each will include the following: 



<UsageInclication> 
<Timestamp> 
<Role> 

<TransactionId> 
<CallId> 

<SourceInfo type="el64"> 
< Sour ceAlte mate 

type="transport "> 

<DestinationInfo 

type="el64 "> 

<DestinationAlternate 

type="transport "> 
<FailureReason> 
<UsageInclication> 
<Timestamp> 
<Role> 

<TransactionId> 
<CallId> 

<SourceInfo type="el64"> 
OourceAlternate 

type="transport "> 

<DestinationInfo 

type="el64 "> 

<DestinationAlternate 



usage information for tine failed setup attempt 

time of request 

for Gateway A, source 

transaction ID assigned by OSP server in autliorization response 

H.323 [12] Call Identifier used for the call 

calling party's E.I 64 [11] number, e.g. 14048724887 

DNS name or IP address of Gateway A, for example 

gatewayA. carrier . com 

called party's E.I 64 [11] number as returned in the authorization 
response, e.g. 33492944299 

DNS name or IP address of Gateway B, for example, 

gateways . itsp . f r 

reason for failure of attempted setup, e.g. 422 

usage information for the successful setup attempt 

time of request 

for Gateway A, source 

transaction ID assigned by OSP server in authorization response 

H.323 [12] Call Identifier used for the call 

calling party's E.164 [11] number, e.g. 14048724887 

DNS name or IP address of Gateway A, for example 

gatekeeperA. carrier . com 

called party's E.164 [1 1] number as returned in the authorization 
response, e.g. 33492944299 

DNS name or IP address of Gateway C, for example, 

gatewayC .isp.fr 



type="transport "> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 



usage information for the call 

empty (for basic service) 

amount of service used, e.g. 300 

increment of service measurement, e.g. i 

unit of service measurement, e.g. s for seconds 

The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 
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Gateway C also sends a <UsageIndication> to the OSP server. That message would include the following 
elements: 



<Timestamp> 

<Role> 

<TransactionIci> 

<CallId> 

<SourceInfo type="el64"> 

< Sour ceAlte mate 

type=" transport "> 

<DestinationInf o type="el64"> 

<DestinationAlternate 

type="transport "> 

<UsageDetail> 

<Service/> 

<Amount> 

<Increment> 

<Unit> 

<Statistics> 

<LossSent> 

<Packets> 

<Fraction> 
<LossReceivecl> 

<Packets> 

<Fraction> 
<OneWayDelay> 

<Minimum> 

<Mean> 

<Variance> 

<Samples> 
<RoundTripDelay> 

<Minimum> 

<Mean> 

<Variance> 

<Samples> 



time of request 

for Gateway C, destination 

Transaction ID assigned by OSP server and passed to Gateway 

in autfiorization token 

H.323 [12] Gall Identifier used for the call 

calling party's E.164 [11] number as presented in the Setup 

message, e.g. 14048724887 

DNS name or IP address of Gateway A, for example 

[172.16.100.1] 

called party's E.164 [11] number, e.g. 33492944299 

DNS name or IP address of Gateway 0, for example, 

gatewayC . itsp . f r 

usage information for the call 

empty (for basic service) 

amount of service used, e.g. 300 

Increment of service measurement, e.g. i 

unit of service measurement, e.g. s for seconds 

statistical information for call 

loss information for packets sent by Gateway 

number of packets lost from Gateway to Gateway A 

fraction (from to 255) of packets lost from to A 

loss information for packets sent by Gateway A 

number of packets lost from Gateway A to Gateway 

fraction (from to 255) of packets lost from A to 

one way delay measured from A to 

minimum measured value for delay, in seconds 

sample mean of delay measurements, in seconds 

sample variance of delay measurements, in squared seconds 

number of sample measurements 

round trip delay between A and measured during call 

minimum measured value for delay, in seconds 

sample mean of delay measurements, in seconds 

sample variance of delay measurements, in squared seconds 



number of sample measurements 

The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 



J. 1.3. 2 Session Initiation Protocol Redirect Servers 

Session Initiation Protocol (SIP) redirect servers represent another example of the loosely coupled distributed 
architecture, particularly on the source side of a call. In this environment, the redirect server provides the call routing 
and authorization on behalf of the systems it serves, but those systems themselves report usage information. 
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J. 1 .3.2.1 Call Routing and Authorization 

Figure J. 11 shows a sample routing and authorization scenario for SIP redirect servers. 
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Figure J. 11 

Gateway A begins a call by sending a SIP INVITE method to its redirect server. The INVITE indicates that the called 
party is identified by an E. 164 [11] phone number such as +33 4 92 94 42 99. 

The Redirect Server sends an OSP <AuthorizationRequest> message to the OSP Server. The significant 
elements within the <AuthorizationRequest> include: 



<Timestamp> 

<CallId> 

<SourceInfo type="el64"> 



< Sour ceAlte mate 



time of request 

SIP Call-ID to be used for the call 

calling party's E.I 64 [11] number if available; otherwise a local 

E.164 [11] number controlled by Gateway A (e.g. 14048724887); this 

number shall be passed to the destination gateway(s) in future INVITE 

messages 

DNS name or IP address of Redirect Server, for example 

redirect . carrier . com 



type="transpor 
t"> 



<sourceAiternate type="h323"> DNS name or IP address of Gateway A, for example 

gatewayA. carrier .com; the type "h323", in this case, implies a 
device-specific ID rather than a particular protocol 
called party's E.164 [11] number, e.g. 33492944299 

empty (for basic service) 

the maximum number of destinations, including alternatives. Redirect 
Server will consider 



<DestinationInf o type="el64"> 

<Service/> 

<MaximumDestinations> 
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OSP Server replies with an <AuthorizationResponse> message. The message identifies Gateway B and 
Gateway C as candidate destinations. In particular, the <AuthorizationResponse> contains the following 
elements: 



<Timestamp> 
<Status> 
<TransactionIcl> 
<Destination> 



time of response 

result of response, e.g. <Code>200</Code> 

transaction identifier assigned by settlement provider 

first destination gateway to try for call 

DNS name or IP address of Gateway B, for example 

<DestinationS gatewayB . it sp . f r 
ignal Address 

type="transpo 



rt"> 
<Token> 
<ValidAfter> 
<ValidUntil> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
<CallId> 
<Destination> 



<DestinationS 
ignal Address 

type="transpo 



authorization token to be passed to Gateway B 
time after which token for Gateway B is valid 
time until which token for Gateway B is valid 
how much service is authorized with Gateway B 
empty (for basic service) 
amount of authorized service, e.g. 3 600 
increment of service measurement, e.g. i 
unit of service measurement, e.g. s for seconds 
SIP Call-ID to be used for the call to Gateway B 
second destination gateway to try for call 

DNS name or IP address of Gateway G, for example 

gatewayC .isp.fr 



rt"> 
<Token> 
<ValidAfter> 
<ValidUntil> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
<CallId> 



authorization token to be passed to Gateway 

time after which token for Gateway is valid 

time until which token for Gateway is valid 

how much service is authorized with Gateway 

empty (for basic service) 

amount of authorized service, e.g. 3 600 

increment of service measurement, e.g. i 

unit of service measurement, e.g. s for seconds 

SIP Call-ID to be used for the call to Gateway C 

The Redirect Server returns a "300 Multiple Choices" redirection status code to Gateway A. This response relays the 
data from the <AuthorizationResponse> to the gateway, explicitly identifying Gateways B and C as candidate 
destinations. This response shall also include the authorization tokens returned by the OSP Server as 
application/osp-token MIME types in the response body. 

Gateway A sends an INVITE message to Gateway B. This INVITE message uses the SIP Call-ID from the 
<AuthorizationRequest>, and the message shall include all authorization tokens associated with that destination 
in the server's OSP <AuthorizationResponse>. 

Gateway B refuses the setup attempt with a 503 message, perhaps, for example, because no outbound PSTN ports are 
available. 

Gateway A tries a second setup attempt, this time by sending an INVITE message to Gateway C. 

Gateway C receives the INVITE message and accepts the call by responding with a 200 message, to which Gateway A 
replies with an ACK. 
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J. 1.3.2. 2 Usage reports 

Once the call has ended, both gateways report usage details to an OSP server. As figure J. 12 indicates, those reports are 
conveyed in OSP <UsageIndication> messages. 



SIP Gateway A 




o 
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Figure J. 12 

The steps shown in figure J. 12 are straightforward. 
Gateways A and C clear the call with a SIP BYE message. 
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Gateway A sends a <UsageIndication> message to the OSP server. In this example Gateway A's message will include 
two complete <UsageIndication> components, one for the failed attempt and one for the successful call. 
The sub-elements for each will include the following: 



<UsageInclication> 
<Timestamp> 
<Role> 

<TransactionIcl> 
<CallId> 

<SourceInfo type="el64"> 
<SourceAlternate 

type="transport "> 

<DestinationInfo 

type="el64 "> 

<DestinationAlternate 

type="transport "> 
<FailureReason> 
<UsageInclication> 
<Timestamp> 
<Role> 

<TransactionId> 
<CallId> 

<SourceInfo type="el64"> 
OourceAlternate 

type="transport "> 

<DestinationInfo 

type="el64 "> 

<DestinationAlternate 



usage information for the failed setup attempt 

time of request 

for Gateway A, source 

transaction ID assigned by OSP server in autliorization response 

SIP Call-ID used fertile call 

calling party's E.164 [11] number, e.g. 14048724887 

DNS name or IP address of Gateway A, for example 

gatewayA. carrier . com 

called party's E.164 [1 1] number as returned in the authorization 
response, e.g. 33492944299 

DNS name or IP address of Gateway B, for example, 

gateways . itsp . f r 

reason for failure of attempted setup, e.g. 422 

usage information for the successful setup attempt 

time of request 

for Gateway A, source 

transaction ID assigned by OSP server in authorization response 

H.323 [12] Call Identifier used for the call 

calling party's E.164 [11] number, e.g. 14048724887 

DNS name or IP address of Gateway A, for example 

gatewayA. carrier . com 

called party's E.164 [1 1] number as returned in the authorization 
response, e.g. 33492944299 

DNS name or IP address of Gateway C, for example, 

gatewayC .isp.fr 



type=" transport "> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 



usage information for the call 

empty (for basic service) 

amount of service used, e.g. 300 

increment of service measurement, e.g. i 

Unit of service measurement, e.g. s for seconds 

The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 

Gateway C also sends a <UsageIndication> to the OSP server. That message would include the following 
elements: 



<Timestamp> 

<Role> 

<TransactionId> 

<CallId> 

<SourceInfo type="el64"> 

< Sour ceAlte mate 

type=" transport "> 

<DestinationInf o type="el64"> 

<DestinationAlternate 



time of request 

For Gateway C, destination 

transaction ID assigned by OSP server and passed to Gateway 
C in authorization token 
SIP Call-ID used for the call 

calling party's E.164 [11] number as presented in the INVITE 

message, e.g. 14048724887 

DNS name or IP address of Gateway A, for example 

[172.16.1.1] 

called party's E.164 [11] number, e.g. 33492944299 

DNS name or IP address of Gateway C, for example, 

gatewayC . isp . f r 
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type= 
<UsageDetail> 

<Service/> 

<Amount> 

<Increment> 

<Unit> 
<Statistics> 

<LossSent> 

<Packets> 
<Fraction> 

<LossReceivecl> 
<Packets> 
<Fraction> 

<OneWayDelay> 
<Minimum> 
<Mean> 
<Variance> 
<Samples> 

<RoundTripDelay> 
<Minimum> 
<Mean> 
<Variance> 
<Samples> 



"transport "> 



usage information for the call 

empty (for basic service) 

amount of service used, e.g. 300 

increment of service measurement, e.g. i 

unit of service measurement, e.g. s for seconds 

statistical information for call 

loss information for packets sent by Gateway C 

number of packets lost from Gateway C to Gateway A 

fraction (from to 255) of packets lost from to A 

loss information for packets sent by Gateway A 

number of packets lost from Gateway A to Gateway 

fraction (from to 255) of packets lost from A to C 

one way delay measured from Gateway A to 

minimum measured value for delay, in seconds 

sample mean of delay measurements, in seconds 

sample variance of delay measurements, in squared seconds 

number of sample measurements 

round trip delay between Gateway A and measured during call 

minimum measured value for delay, in seconds 

sample mean of delay measurements, in seconds 

sample variance of delay measurements, in squared seconds 



number of sample measurements 

The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 
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J.2 Prepaid calling card and roaming user support 

As figure J. 13 shows, the most general environment requires support from four different domains: the source and 
destination domains of the IP telephony gateways, the settlement service provider, and the end user billing domain. 
User billing may distinct from the source domain in the case, for example, or a roaming user. 

Figure J. 13 also shows the general operational procedure for authorization divided into seven discrete steps. 



Source Domain 



Destination Domairl 




Settlement Provider 



End User Billing 



Figure J. 13 

The user accesses a gateway in the source domain. The gateway, perhaps using an IVR application, collects the user's 
calling card number and personal identification number, in addition to the called number. 

The source gateway forwards this information to the settlement provider in an OSP <AuthorizationRequest>. 

The settlement provider, in addition to authenticating the source gateway, also authenticates the end user. That 
authentication procedure is outside the scope of OSP, but may, as the example shows, rely on another standard protocol 
such as RADIUS (RFC 2138, see bibliography). 

The end user billing application authenticates and authorizes the user. 

The settlement provider returns an <AuthorizationResponse> to the source gateway indicating acceptance of 
the end user and providing authorization tokens for the destination gateway. 

The call proceeds normally with a Setup message from the source to the destination gateway. 

The destination gateway completes the call to the called party. 

These steps represent the beginning of a calling card transaction. Additional phases, including refreshing the user's 
authorization and reporting usage information, can be found in the following clause on implementation details. 
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J.2.1 Call routing and authorization 



The OSP <AuthorizationRequest> message shown in step 2 contains the following significant elements: 



<Timestamp> 

<CallId> 

<SourceInfo type="el64"> 



<SourceAlternate 



Time of request 

H.323 [1 2] Call Identifier to be used for the call 

Calling party's E.164 [11] number if available; otherwise a local E.I 64 

[11] number controlled by the source gateway, e.g. 14048724887; 

this number shall be passed to the destination gateway(s) in Setup 

messages 

DNS name or IP address of source gateway, for example 

sourcegateway . carrier . com 



type="transpor 
t"> 



< Sour ceAlte mate 



The user's calling card and PIN; following conventions established by 
the Voice over IP Forum, these should be combined into a single 
type="subscrib character string, with the two components separated by the pound 
<^^"> sign (#). For example, the calling card number 12345678, combined 

with the PIN 4444, should be represented as "12345678#4444". 

<DestinationInfo type="el64"> Called party's E.164 [1 1] number, e.g. 33492944299 



<Service/> 
<iyiaximumDestinations> 



Empty (for basic service) 

The maximum number of destinations, including alternatives, the 

source gateway will consider 
The OSP server replies with an <AuthorizationResponse> message as the figure indicates in step 5. The 
message indicates candidate destination gateways, in order of priority. In this example (which only shows a single 
destination gateway, the OSP <AuthorizationResponse> contains the following elements: 



<Timestamp> 
<Status> 
<TransactionIcl> 
<Destination> 

<DestinationSignalAclclress 

type="transpor 
t"> 

<Token> 

<ValidAfter> 

<ValidUntil> 

<UsageDetail> 

<Service/> 

<Amount> 

<Increment> 

<Unit> 
<CallId> 



time of response 

result of response, e.g. <Code>200</Code> 
transaction identifier assigned by settlement provider 
first destination gateway to try for call 

DNS name or IP address of destination gateway, for example 

de St gateway . itsp. f r 

authorization token to be passed to destination gateway 

time after which token for destination gateway is valid 

time until which token for destination gateway is valid 

how much service is authorized with destination gateway 

empty (for basic service) 

amount of authorized service, e.g. 3 600 

increment of service measurement, e.g. i 

unit of service measurement, e.g. s for seconds 

H.323 [12] Call Identifier to be used for the call to destination gateway 
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J.2.2 Reauthorization 

In many calling card services, it may be necessary to refresh the authorization of a call that is already in progress. For 
example, some debit card applications will only authorize a limited amount of service at any given time; this can 
minimize the risk of fraudulent, simultaneous use of the debit card by multiple users. In such scenarios, and when the 
users wish to continue their conversation past the limited amount of time initially authorized, it will be necessary for the 
supporting devices to request additional authorization for the call. The following figure shows the message flow for this 
process. The six steps figure J. 14 begin when the originating gateway recognizes that the currently authorized service 
limit is approaching. 



Source Domain 




Settlement Provider 



End User Billing 



Figure J. 14 

Source gateway recognizes that the duration currently authorized for the call is nearing its limit. 

Source gateway sends an OSP <ReauthorizationRequest> to the OSP server. 

The OSP server uses some other means (such as RADIUS, in the example) to authorize additional service for the user. 

The OSP server confirms that additional service is authorized. 

The OSP server returns a <ReauthorizationResponse> to the source gateway, granting the additional 
authorized service. The response tells the source gateway the new authorization hmits explicitly, and it includes an 
updated authorization token. 

The source gateway passes the new authorization token to the destination gateway. The exact method of transfer 
depends on the gateway implementations and the particular call signalling protocol; as an example, the source gateway 
may include the token in an H.323 [12] Facility message. 
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The OSP <ReauthorizationRequest> message shown in step 9 contains the following significant elements: 



<Timestamp> 

<Role> 

<CallId> 

<SourceInfo type="el64"> 



< Sour ceAlte mate 



type="transpor 
t"> 



<SourceAlternate 



type=" subs crib 
er"> 



<DestinationInf o type="el64"> 

<DestinationAlternate 



type="transpor 
t"> 



<TransactionId> 
<UsageDetail> 
<Service/> 
<Amount> 
<Increment> 
<Unit> 
<Token> 



Time of request 

for the source gateway, source 

H.323 [12] Call Identifier used for the call 

Calling party's E.164 [11] number if available; otherwise a local 
E.I 64 [11] number controlled by the source gateway, e.g. 
14048724887; thisnumber shall be passed to the destination 
gateway(s) in Setup messages 

DNS name or IP address of source gateway, for example 
sourcegateway . carrier . com 



The user's calling card and PIN; following conventions established by 
the Voice over IP Forum, these should be combined into a single 
character string, with the two components separated by the pound 
sign (#). For example, the calling card number 12345678, combined 
with the PIN 4444, should be represented as "12345678#4444". 
Called party's E.164 [11] number, e.g. 33492944299 

DNS name or IP address of destination gateway, for example, 

de St gateway . itsp. f r 



transaction Identifier assigned by settlement provider 

usage information for the call so far 

empty (for basic service) 

amount of service used so far, e.g. 300 

increment of service measurement, e.g. i 

unit of service measurement, e.g. s for seconds 

authorization token to be passed to destination gateway 



The OSP server returns that information within an <ReauthorizationResponse> message, as figure J. 14 
indicates in step 12. The message refreshes the authorization information for the call. In this example, the OSP 
<AuthorizationResponse> contains the following elements: 



<Timestamp> 
<Status> 
<TransactionId> 
<Destination> 

<DestinationSignalAddress 

type="transpor 
t"> 

<Token> 

<ValidAfter> 

<ValidUntil> 

<UsageDetail> 

<Service/> 
<Amount> 
<Increment> 
<Unit> 



time of response 

result of response, e.g. <Code>200</Code> 
transaction identifier assigned by settlement provider 
destination gateway to try for call 

DNS name or IP address of destination gateway, for example 

de St gateway . itsp. f r 

updated authorization token to be passed to destination gateway 

time after which token for destination gateway is valid 

time until which token for destination gateway is valid 

how much (cumulative) service is authorized with destination 

gateway 

empty (for basic service) 

(cumulative) amount of authorized service, e.g. 3600 

increment of service measurement, e.g. i 

unit of service measurement, e.g. s for seconds 
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Once the call has ended, both gateways report usage details to an OSP server. As figure J. 15 indicates, those reports are 
conveyed in OSP <UsageIndication> messages. 



Source Domain 



Destination Domain 




Figure J. 15 

The steps shown in the figure are straightforward. 

The gateways clear the call by exchanging an H. 225.0 [8] Release Complete message. 

The source gateway sends a <UsageIndication> message to the OSP server, reporting its usage details for the call. 

The OSP server acknowledges receipt with a <UsageConf irmation> message. 

The destination gateway also reports its usage details with a <UsageIndication> message. 

The server acknowledges this message as well with a <UsageConf irmation>. 

The <UsageIndication> messages from both gateways will be substantially the same. As an example, here are the 
significant fields of the source gateway's message: 



<Timestamp> 

<Role> 

<TransactionId> 

<CallId> 

<SourceInfo type="el64"> 

< Sour ceAlte mate 



time of request 

for source gateway, source 

transaction ID assigned by OSP server in authorization response 

H.323 [12] Call Identifier used for the call 

calling party's E.I 64 [11] number as returned in the authorization 

response, e.g. 14048724887 

DNS name or IP address of source gateway, for example 

sourcegateway . carrier . com 



type="transpor 
t"> 

<DestinationInfo type="el64"> Called party's E.164 [11] number, e.g. 33492944299 
<DestinationAlternate 



DNS name or IP address of destination gateway, for example, 

destgateway . isp . f r 



type="transpor 
t"> 



<UsageDetail> 



usage information for the call 
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<service/> empty (for basic service) 

<Amount> aiTiount of service used, e.g. 600 

<increment> Increment of service measurement, e.g. i 

<unit> unit of service measurement, e.g. s for seconds 

The OSP server responds with a <UsageConf irmation> message. If it has accepted the usage report, that message 
will contain a successful <Status> element (e.g. <Code>200</Code>). 
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Annex K (informative): 

OSP token format for SIP headers 



This annex documents a private Session Initiation Protocol (SIP) [36] header field that may be used to exchange Open 
Settlement Protocol (OSP) authorization tokens in the context of SIP session establishment. 



K.O Design alternatives 



The OSP Token is an opaque string to SIP which must be carried in the INVITE passed between domains. As such, the 
Token could be carried as a MIME attachment. However, there are three issues with this: 

• Since the Token must be carried with the SDP, the INVITE would need to have a multipart MIME message 
body. If either User Agents do not support multipart MIME, the call will fail. 

• The Token is used by both proxies and User Agents. As such, the proxy would have to decode the multipart 
MIME message body to extract the token. The general design of SIP is for message bodies to contain 
information of interest to end-points only, with information needed by proxies contained in headers. 

• Multipart MIME encoding/decoding adds more delay to an already lengthy call setup procedure, as compared 
to header processing. 

For these reasons, a new SIP header field is proposed instead of a new MIME type for OSP authorization tokens. 

Note that since OSP tokens are commonly constructed according to Cryptographic Message Syntax [28], their size may 
depend on the size of X.509 certificates embedded in the CMS format. For this reason, entities using this header MUST 
NOT use UDP for transport. Instead TLS SHOULD be used. In addition, it is recommended that systems use the 
abbreviated token format described in annex D. 



K.1 Header field definition 

The table below specifies an extension of table 2 in RFC 3261 [36] for the header defined here. 





where 


proxy 


ACK 


BYE 


CAN 


INV 


OPT 


REG 


P-OSP-Auth-Token 


R 


ad 


- 


- 


- 


o 


- 


- 


P-OSP-Auth-Token 


2xx 


ad 


- 


- 


- 





- 


- 



The "where" column describes the request and response types with which the header field can be used. "R" indicates a 
request header, a numeric value in the "where" column indicates the status code the header field is used with. The 
"proxy" column describes whether this message header field MAY be added, "a", or deleted, "d", by a proxy server. In 
the method columns, "o" means optional and "-" means not applicable. 

The Augmented BNF for the header field (using the form and definitions in clause 25 of RFC 3261 [36]) is: 

P-OSP-Auth-Token = "P-OSP-Auth-Token" HCOLON token 



K.2 Protocol semantics 



The OSP Token is always encoded per base64 and only allowed in INVITE requests and 200 OK responses to 
INVITES. 
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K.2.1 User agents 



A UAC MAY include the header field in an INVITE requesting QoS using AAA. If present in an INVITE, an 
AAA/QoS UAS MAY validate the token. If it is absent or present in the INVITE, an AAA/QoS UAS MAY include the 
header field in a 200 OK answer. A UAC MAY validate the token received in a 200 OK response to an INVITE. 

K.2.2 Proxies 

A proxy participating in the AAA exchange may add, delete, examine or validate the token. Otherwise, the header field 
is ignored. 

K.2.3 Example message 

This SIP INVITE message is an example exchange between two domains: 

INVITE sips :+l-972-555-5555@doinain2 .coin;user=phone SIP/2.0 

Via: SIP/2. 0/TLS proxy . domainl . com: 5061; branch=z9hG4bK3a56d3 . 1 

Via: 

SIP/2 . 0/TLSphonel .domainl .com: 50 61 ; branch=z9hG4bK3a5 654 ; received=192 .0.2.1 

Max-Forward: 69 

From: Alice <sips : alice@phonel . domainl . com>; tag=3 

To : <sips : +l-972-555-5555@domain2 . com; user=phone> 

Call-ID: 123456@domainl.com 

CSeq: 1 INVITE 

Contact : <sips : alice@phonel . domainl . com> 

Record-Route : <sips : proxy . domainl . com; lr> 

P-OSP-Auth-Token : 

"YT64VqpfyF4 67GhIGfHfYT6 jH7 7n8HHGghyHhHUujhJh7 5 6tHGTrfvbnjn8HHGTrfvhJhjH7 7 

6tbB9HG4VQbnj75 67GhIGfH6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj" 

Content-Type: application/sdp 

Content-Length: 184 

v=0 

o=alice 9735285123 9721273312 IN IP4 phonel.domainl.com 

s=- 

c=IN IP4 phonel.domainl.com 

t = 

m=audio 9876 RTP/AVP 

a=rtpmap: PCMU/8000 

a=qos :mandatory recv confirm 



K.2.4 lANA considerations 

This document defines a new private SIP header field, "P-OSP-Auth-Token". As recommended by the policy of the 
IETF Transport Area and by RFC 3427 [37], this header should be registered by the I AN A in the SIP header field 
registry, using the appropriate document as its reference. 
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K.2.5 ISOC copyright notice for annex K 

Material in annex K of the present document is derivative work based on an IETF draft carrying the following notice: 

"Copyright (C) The Internet Society 2003. All Rights Reserved. 

The present document and translations of it may be copied and furnished to others, and derivative works that comment 
on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole 
or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on 
all such copies and derivative works. However, the present document itself may not be modified in any way, such as by 
removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for 
the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet 
Standards process must be followed, or as required to translate it into languages other than English. 

The deleted IETF draft carrying this notice was publicly available at: 

http://www.ietf.org/internet-drafts/draft-iohnston-sip-osp-token-04.txt 
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